[feat][ml] Add stateless RandomReader to ManagedLedger

[dao-jun]

Motivation

Add stateless RandomReader to ML.

Today every read path in managed-ledger goes through a ManagedCursor. A cursor is comparatively heavyweight for several access patterns:

1. Cursorless reads for downstream consumers. Reading via a cursor requires acknowledging entries — any un-acked read grows the backlog and interferes with retention/trimming. Reading messages scattered across arbitrary positions further requires repeated seek operations. A lightweight, stateless reader (no position, no
   ack, no backlog, no trimming hold) lets downstream projects batch-read entries directly by position, without those side effects.
2. Cursorless batch reads for Pulsar itself. Internal components that only need to fetch entries at given positions (backfill, repair, offset-based lookups) currently pay the full cursor overhead. A cursorless primitive gives them a cheaper path.
3. Groundwork for a future RandomReader client. This PR provides the server-side managed-ledger primitive that a planned RandomReader client will build on. That client is intended to support both pure random reads (serving metadata-style lookups) and sequential reads (serving stream-processing frameworks such as Flink).

Modifications

• Introduce RandomReader, a cursorless, stateless reader (public final class ... implements AutoCloseable) in the managed-ledger impl package — renamed from the former RandomReaderImpl; the previous RandomReader interface is removed. A reader maintains no read position, performs no ack, contributes no backlog, and does
  not prevent ledger trimming; reads do not wait for future entries, and callers must release every returned Entry. Reads honor count, position (maxPosition, inclusive), and estimated-size limits.
• Back it with RandomReaders (a per-managed-ledger reader registry) and OpRandomReadEntries (the cross-ledger batch-read operation), both in the impl package. RandomReader instances are created only via RandomReaders#create(boolean populateCache) (package-private constructor).
• Expose creation through ManagedLedgerImpl#randomReaders() (returning the registry) rather than on the ManagedLedger interface, since RandomReader support is bound to ManagedLedgerImpl's entry cache and is not a pluggable contract. Reader lifecycle is tied to managed-ledger close/fence.
• Integrate with the entry cache: a populateCache=true reader writes read misses back to the cache and seeds the write tail, and contributes to the add-path expectedReadCount (via OpAddEntry / EntryReadCountHandlerImpl) so cache-eviction weight reflects active random readers; shouldCacheAddedEntry() now also accounts for
  them. A populateCache=false reader serves cache hits without write-back, avoiding cache pollution for truly random, low-frequency access (cache integration touches EntryCache / RangeEntryCacheImpl).
• Add unit tests in ManagedLedgerTest covering read semantics, position/size boundaries, cross-ledger reads, error/partial results, close/fence lifecycle, and both cache modes.

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

[BewareMyPower]

expected read count is not taken carefully.

In EntryImpl:

    protected void deallocate() {
        if (decreaseReadCountOnRelease && readCountHandler != null) {
            readCountHandler.markRead();
        }

The read count will always be decreased no matter whether the read op is on a RandomReader. This could affect the cache eviction strategy

[dao-jun]

@BewareMyPower fixed, PTAL