feat: Add Transaction Interceptor Support for Retry & Resilience Handling

[Aamir377300]

Problem

While looking through the transaction execution flow, I noticed that handling retries for temporary failures currently has to be done manually by the application.

In some cases, transactions can fail because a node is temporarily BUSY or due to short-lived network issues. Right now, there doesn’t seem to be a shared way to handle these scenarios centrally, so developers may end up writing similar retry logic in multiple places.

Proposed Idea

It could be useful to introduce a TransactionInterceptor layer around the transaction.execute() phase, similar to a middleware/interceptor pattern.

This would make it easier to plug in reusable behaviors like:

• retry handling
• exponential backoff
• logging
• tracing/metrics

without changing transaction code throughout the application.

A possible direction could be:

• adding a TransactionInterceptor interface
• allowing ProtocolLayerClientImpl to execute transactions through an interceptor chain
• providing a default retry interceptor for transient failures such as BUSY

For example:

ExponentialBackoffRetryInterceptor

could automatically retry temporary failures with configurable retry limits and delays.

please assign this issue to me and i am open for discussion and feedback.