Review the client and retry features in the SDKs

### Problem

**Client**
Client Instantiation: When the client application starts up, it selects a random subset of nodes (1/3 of the total nodes) from the network and designates them for pre-signing transactions.

Client Persistence: If the client application remains open for the entire duration of its operation, it will continue to use the initially selected subset of nodes for transaction pre-signing. This means it won't interact with the rest of the nodes on the network.

Limited Node Usage: Due to the persistence of the client's selection, the application's transactions will only circulate among the 10 nodes from the original subset, rather than involving all 30 nodes in the network.

New Client Initialization: If a new instance of the client application is started, it will again randomly select a fresh subset of nodes (1/3 of the total nodes) for transaction pre-signing.

Single Client Instantiation: Most applications likely only instantiate the client once, which means they will continue to use the same initial subset of nodes throughout their operation.

Ultimately, the goal is to achieve a fair distribution of transactions across the entire node network, ensuring efficient utilization and preventing potential performance bottlenecks.

**Retrying Transactions**
The SDK has a retry feature such that when a transaction is submitted to the network the transaction retries if the transaction failed to be accepted by the first node in the transaction list. The transactions are pre signed each with a different node ID ahead of time. So if a transaction that is submitted to the first node in the list fails it will try to submit the next pre-signed transaction in the list. There is a default value in the SDK for the max retry attempts. This value is set to 10. Each transaction has a transaction valid duration period for 180 seconds. The feedback was that the transaction should continue to submit to a node until the max valid duration limit is met and the transaction is expired. We will need to review what impacts this might have because the user might be waiting a long time for the transaction to execute if we retry until the 180 second is reached before trying the next transaction in the list.

Extended User Wait Times: If the system retries a transaction until its validity period expires, users might experience longer waiting times for their transactions to be processed. This could be frustrating for users who expect quicker transaction confirmations.

Resource Utilization: Constantly retrying transactions until the validity period expires could tie up system resources and connections, potentially impacting the overall performance of the system.

Network Congestion: If transactions that are bound to fail are retried until expiration, it could lead to unnecessary network congestion and load on the nodes.

Delayed Feedback: Users might not receive prompt feedback about transaction failures, as the system would keep trying for the entire validity period before moving on to the next pre-signed transaction.

### Solution

- [ ] Document the current behavior of the client
- [ ] Document the current behavior for retrying transactions
- [ ] Identify optimizations we can make without introducing breaking changes to improve the developer experience
- [ ] Review the proposed optimizations with the architect team
- [ ] Document the tests required to test the optimizations work as intended
- [ ] Implement the agreed upon solution in a future sprint across all SDKs

### Alternatives

_No response_