[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:

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 91.39785% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 73.12%. Comparing base (bbc6224) to head (ec248c0).
Report is 236 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #22560      +/-   ##
============================================
- Coverage     73.57%   73.12%   -0.45%     
- Complexity    32624    32763     +139     
============================================
  Files          1877     1887      +10     
  Lines        139502   141127    +1625     
  Branches      15299    15490     +191     
============================================
+ Hits         102638   103199     +561     
- Misses        28908    29959    +1051     
- Partials       7956     7969      +13     

Flag	Coverage Δ
inttests	27.39% <43.01%> (+2.80%)	⬆️
systests	24.70% <43.01%> (+0.38%)	⬆️
unittests	72.12% <91.39%> (-0.72%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...che/bookkeeper/mledger/impl/ManagedCursorImpl.java	79.62% <100.00%> (+0.32%)	⬆️
...rg/apache/bookkeeper/mledger/impl/OpReadEntry.java	84.61% <100.00%> (+0.30%)	⬆️
...che/bookkeeper/mledger/impl/ManagedLedgerImpl.java	81.12% <90.36%> (+0.46%)	⬆️

... and 328 files with indirect coverage changes

[lhotari]

@dao-jun Thanks for the contribution. This looks like an important PR. Please rebase.

[dao-jun]

@lhotari Rebased