[fix][ml] Close abandoned write ledger handle to prevent leak - #26585

Motivation

When an add-entry fails or a ledger is detected as concurrently modified, the managed ledger switches to a new ledger but never closes the old write handle. An open write handle keeps its periodic explicit-LAC flush task scheduled on the BookKeeper client scheduler, so every such ledger leaks the handle and the task for the lifetime of the broker.

In a long-running broker this accumulates: heap-dump analysis showed ~280k LedgerHandle objects (vs. ~1.7k ledgers tracked by the managed ledgers), each with a 1s-period explicit-LAC flush task pinned in a single scheduler delay queue that retained ~997MB (67.8% of the heap). The resulting LAC flush storm keeps the scheduler thread busy re-heapifying the delay queue, starving BookKeeper read callbacks and stalling consumer dispatch.

Modifications

• OpAddEntry#handleAddFailure: close the failed ledger before switching to a new one, mirroring rollCurrentLedgerIfFull, and only then trigger ledgerClosed.
• ManagedLedgerImpl#addEntryFailedDueToConcurrentlyModified: close the abandoned write handle after switching to a new ledger.
• PulsarMockLedgerHandle: track asyncClose() invocations so tests can assert handles are closed instead of merely abandoned.
• Add/update positive tests verifying the failed/concurrently modified handle is closed and writes recover on a new ledger.

Evidence

Two heap dumps of the same broker process (5 minutes apart) both show the leak:

The managed ledgers only track ~1.7k ledgers in metadata, so ~279k write handles are orphaned (switched away from but never closed). Every leaked handle keeps a 1-second explicit-LAC flush task alive; org.eclipse.mat.api:suspects reports one scheduler DelayedWorkQueue retaining 997MB (67.8% of heap) with the scheduler thread caught in siftDown.

Verifying this change

This change added tests and can be verified as follows:

• ManagedLedgerErrorsTest#writeErrorClosesFailedLedgerHandle: a write error on the current ledger must close the failed handle exactly once, switch to a new ledger and keep writes working.
• ManagedLedgerErrorsTest#concurrentlyModifiedLedgerHandleIsClosedAndWritesRecover: a LedgerFencedException (concurrently modified ledger) must close the abandoned handle and recover on a new ledger.
• ManagedLedgerErrorsTest#recoverLongTimeAfterMultipleWriteErrors: extended to assert the failed handle is closed after multiple write errors.

All 22 tests in ManagedLedgerErrorsTest pass; :managed-ledger:checkstyleMain, :managed-ledger:checkstyleTest and :testmocks:checkstyleMain pass.