[fix][meta] Run ledger-underreplication notification callbacks off the metadata-store listener thread

[merlimat]

Motivation

PulsarLedgerUnderreplicationManager.handleNotification is registered as the metadata-store change listener and runs on the metadata-store notification thread, inside synchronized(this). When a relevant z-node changed, it invoked the registered BookKeeper GenericCallbacks (replicationEnabledCallbacks / lostBookieRecoveryDelayCallbacks) inline. Those callbacks can perform synchronous metadata-store reads (the class itself documents this near notifyUnderReplicationLedgerChanged), so they blocked the metadata-store notification thread — and held the manager's monitor — while doing metadata I/O.

Modifications

Run the registered callbacks on a dedicated single-threaded executor instead of the notification thread. The callback list is still snapshotted and cleared synchronously under the monitor, and notifyAll() (the primary wait/notify used by the blocking poll methods) stays synchronous; only the callback invocation is offloaded, so it runs off the notification thread and without holding the monitor. The single thread preserves notification ordering, and close() shuts the executor down. Callbacks re-read current state when they re-register, so this is eventually consistent.

Verifying this change

Covered by existing LedgerUnderreplicationManagerTest (87 executions across metadata-store implementations), which awaits callbacks via Awaitility/latches — passes.

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