RPC node doesn't retry sending transactions

[garious]

Problem

RPC node doesn't retry sending transactions, so each client has to implement the same retry algorithm, and lazy clients probably won't implement exponential backoff, causing unnecessary network congestion.

Proposed Solution

Add RpcClient::send_transaction_and_wait_until_accepted() and corresponding JSON RPC API. The RPC node should retry on behalf of the client. It should share the same retry code as what is used for #9400.

Ideally, the RPC node implementation could use async/await, not one thread per connection.

cc: @mvines @CriesofCarrots @aeyakovenko

[mvines]

We could only retry transactions:

1. That pass signature check
2. That can pay the transaction fee (based on the max confirmed bank of the RPC node)
3. Only retry transactions until their blockhash is no longer known to the RPC node

This could just be a simple queue that is checked every ~5-10 seconds. Once a queued transaction's blockhash is no longer known, or the signature shows up in the status cache then drop it.

[mvines]

This would likely help mitigate a current TrustWallet bug where transactions get stuck as "pending" in the TrustWallet UI.

TrustWallet should clearly handle this better, but a retry facility in RPC would reduce the likelihood of users encountering the application bug.

[mvines]

Replaced by #9974