ISSUE-2854: When ScanAndCompareGarbageCollector#removeOverReplicatedledgers is called, underreplicated ledger locks are still acquired.

[sijie]

Original Issue: apache/bookkeeper#2854

---

BUG REPORT

Describe the bug

When ScanAndCompareGarbageCollector#removeOverReplicatedledgers is called, all of underreplicated ledger locks are still acquired. This issue is caused by https://github.com/apache/bookkeeper/pull/2833. In this PR, the method uses LedgerUnderreplicationManager#acquireUnderreplicatedLedger and LedgerUnderreplicationManager#releaseUnderreplicatedLedger instead of ZkLedgerUnderreplicationManager#acquireUnderreplicatedLedgerLock and ZkLedgerUnderreplicationManager#releaseUnderreplicatedLedgerLock.

ZkLedgerUnderreplicationManager#releaseUnderreplicatedLedger requires ZkLedgerUnderreplicationManager#heldLocks to delete lock node. However, ZkLedgerUnderreplicationManager#acquireUnderreplicatedLedger doesn't put lock instance to heldLocks. Therefore, can't remove lock z-node.

Moreover, ZkLedgerUnderreplicationManager#acquireUnderreplicatedLedger creates /ledgers/underreplication/locks/urL${ledgerId}/underreplication/locks/urL${ledgerId} node. It has redundant path urL${ledgerId}/underreplication/locks/ by non ephemeral z-node. I think /ledgers/underreplication/locks/urL${ledgerId} is correct.

I think this issue blocks the release. I will fix the issue.

To Reproduce

Steps to reproduce the behavior:

1. Run ScanAndCompareGarbageCollector#removeOverReplicatedledgers with ZKMetadataBookieDriver
2. Check underreplicated ledger lock

Expected behavior

• ZkLedgerUnderreplicationManager#acquireUnderreplicatedLedger will create lock node with correct path.
• ScanAndCompareGarbageCollector#removeOverReplicatedledgers will remove lock z-node when the process is completed.