[improve][broker] Prevent stale replicator pending reads after termination

[Denovo1998]

Fixes #xyz

Main Issue: #xyz

PIP: #xyz

Motivation

This is a follow-up to #25625 for the replication read-failure path related to #25097.

#25625 completes a replicator InFlightTask when a managed-ledger read fails, so retryable read failures do not leave stale pending-read state behind. This PR improves the state handling for the race where the read failure callback arrives after the replicator has already left Started, for example during termination or producer restart. In that case, readEntriesFailed should still clear the failed read task so the replicator does not keep stale pending-read state while the object is still alive.

Modifications

• Complete failed InFlightTask contexts before checking whether the replicator is still in the Started state.
• Keep the cleanup defensive by only completing contexts that are actually InFlightTask instances.
• Add error logs for unexpected failed-read callback states:
  • the callback context is not an InFlightTask;
  • the InFlightTask already has non-null entries when the failed callback is handled.
• Remove duplicated failed-task completion from the later retry/error branches in readEntriesFailed.
• Add a regression test that starts a real replication read, blocks the managed-ledger read failure, terminates the replicator through the normal lifecycle, releases the failure callback, and verifies the pending-read state is cleared.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[lhotari]

LGTM

[poorbarcode]

Replicator termination only occurs in the two events of "disabling replication" and closing the topic, and these two events will trigger the JVM GC for the replicator object. So this PR only fixes the state of "pending reads" at the moment when "the topic is turned off, and the replicator object has not been GC", and the state "pending reads" at this moment will not cause any problems.

However, this modification is still useful, which makes our project more perfect. I suggest changing the label in the title to "improve". Then in the future, if users discover a replication problem, they won't spend too much time on considering such case

[Denovo1998]

Replicator termination only occurs in the two events of "disabling replication" and closing the topic, and these two events will trigger the JVM GC for the replicator object. So this PR only fixes the state of "pending reads" at the moment when "the topic is turned off, and the replicator object has not been GC", and the state "pending reads" at this moment will not cause any problems.

However, this modification is still useful, which makes our project more perfect. I suggest changing the label in the title to "improve". Then in the future, if users discover a replication problem, they won't spend too much time on considering such case

@poorbarcode Okay. PTAL again.

[poorbarcode]

LGTM