HDDS-16143. Fix durable deleted-block summary undercount from unguarded flush()

[priyeshkaratha]

What changes were proposed in this pull request?

DeletedBlockLogStateManagerImpl.addTransactionsToDB and removeTransactionsFromDB buffer a transaction row and its updated DeletedBlocksTransactionSummary as two separate transactionBuffer calls. SCMStateMachine.notifyLeaderChanged calls transactionBuffer.flush() without the applyingTransactions guard that
flushIfNeeded uses, so a leader change can fire between the row buffer call and the summary buffer call, committing the transaction row to RocksDB without the matching summary update.

SCMDeletedBlockTransactionStatusManager.onBecomeLeader then calls initDataDistributionData, which reloads the now-stale (pre-apply) summary from the inconsistent durable state into the in-memory counters,
overwriting the correct in-memory value. The undercount is permanent — it isn't self-healed by a later flush, only by an SCM restart that reads a subsequent consistent checkpoint.

Add SCMHADBTransactionBuffer#runWithBufferLock(CheckedRunnable). It holds the buffer's shared read lock for the duration of the operation; since flush() takes the write lock, it cannot commit a partial
row+summary batch in the middle of the operation (nested addToBuffer/removeFromBuffer calls re-enter the read lock, which ReentrantReadWriteLock permits). DeletedBlockLogStateManagerImpl wraps the row and summary buffering in both addTransactionsToDB and removeTransactionsFromDB in this call, making each a flush-atomic unit.

Implemented for both SCMHADBTransactionBufferImpl and SCMHADBTransactionBufferStub.

What is the link to the Apache JIRA

HDDS-16143

How was this patch tested?

Added new testcases.