HDDS-16142. Fix double-decrement of deleted-block summary on Ratis timeout

[priyeshkaratha]

What changes were proposed in this pull request?

HDDS-15726 introduced rollback logic that reverts those counters on IOException from addTransactionsToDB / removeTransactionsFromDB. That is correct for definitive failures (not-leader, connection error,
state-machine IO error), but wrong for a Ratis timeout.

SCMRatisServerImpl.submitRequest calls server.submitClientRequestAsync(request).get(requestTimeout, ms)

A TimeoutException from .get() only abandons the client-side wait. The CompletableFuture is discarded, but the in-flight log entry continues through the Ratis pipeline and can still be committed and applied after the caller has already seen the exception. Rolling back the summary at that point produces:

• a double-decrement on the add path (summary goes negative), or
• an overcount on the remove path (summary stays inflated).

Both divergences persist until the next leader transfer, which reconciles the counters by reloading from the durable state via
initDataDistributionData().

Fix

Introduce isRatisTimeout(IOException) to distinguish ambiguous outcomes from definitive failures. The check covers two cases:

• SCMException(ResultCodes.TIMEOUT): translateException maps a java.util.concurrent.TimeoutException to this code.
• SCMException(ResultCodes.INTERNAL_ERROR) whose cause is InterruptedException: .get() can also throw InterruptedException if the thread is interrupted while waiting; the request is already in-flight, giving the same ambiguous outcome as a timeout.

What is the link to the Apache JIRA

HDDS-16142

How was this patch tested?

Tested by added cases and existing tests.

[ChenSammi]

Thanks @priyeshkaratha . This is the question that I thought about during HDDS-15726. The change LGTM.

Thanks @smengcl for raising this issue.