[improve][ml] Optimize read entries with skipCondition

[dao-jun]

Motivation

In #19035 we introduced skipCondition to filter-out delay delivery messages before read entries from Bookkeeper, and in #21739, we also filter-out deleted(individual acked messages) before read entries.

However, it will lead to one situation: one single segment can be spit into segments. For example:
entries to be filter-out: [3, 5, 7]
entries to read: [1, 10]
then, it will be split into: [[1,2],[4], [6], [8,10]].

In the current implementation, after read [1,2] finished, then begin to read [4], after read [4] finished, then start to read [6]...
It will lead to latency increasing, memory(allocated for entries) will also be retained for a longer period of time, and affect the throughput of the system.

Modifications

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

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[lhotari]

@dao-jun This PR will be a good foundation to switching to use BookKeeper's BP-62 Batch Read API (introduced in BK 4.17.0) in Pulsar. One of the gotchas of BP-62 is that a batch read might not return all entries even if there are remaining entries to be read. It seems that it would play nicely with the changes that are made in this PR so that the next read could continue to retry and read more. Would you be interested in implementing BP-62 support in Pulsar after this current PR has been merged?

[dao-jun]

@dao-jun This PR will be a good foundation to switching to use BookKeeper's BP-62 Batch Read API (introduced in BK 4.17.0) in Pulsar. One of the gotchas of BP-62 is that a batch read might not return all entries even if there are remaining entries to be read. It seems that it would play nicely with the changes that are made in this PR so that the next read could continue to retry and read more. Would you be interested in implementing BP-62 support in Pulsar after this current PR has been merged?

@lhotari Yes, I'd like to handle the case. And I created a PR to support Bookie batch read about a year ago, it's not finished yet. dao-jun#13

[lhotari]

@dao-jun Please rebase once again