CLI with --no-wait doesn't retry

[garious]

Problem

Using the --no-wait option with the CLI doesn't retry sending the transaction, which pushes that complexity onto the caller. Specifically, it requires them to get a recent blockhash via solana fees and then guessing how long it can retry before that blockhash expires. Furthermore, the naive implementation would probably retry every ~100ms instead of doing exponential backoff to minimize network congestion.

Proposed Solution 1

Add a new option --confirmations=<NUMBER> that is mutually exclusive with --no-wait. NUMBER should be a number between 0 and 32, and should be the number of confirmations the CLI blocks on before exiting. If NUMBER is 0, it should only block until the transaction has been "accepted". That is, wait until the validator observes the transaction on the ledger; don't wait for a supermajority vote.

While waiting for the transaction to be accepted, the CLI should send retries until the blockhash is expired. The retry algorithm should use exponential backoff, à la TCP. The CLI should not attempt to update the blockhash and re-sign.

Proposed Solution 2

Add two new CLI commands, such that the user can do retries:

• solana recent-blockhash, prints a base58 blockhash.

• solana check-blockhash <BLOCKHASH>, returns 0 if the blockhash is found, and otherwise 1.

Leaning heavily toward Proposal 1, but might want to implement the new commands in Proposal 2 for completeness.

cc: @mvines @CriesofCarrots @aeyakovenko

[CriesofCarrots]

Proposed Solution 2 is now implemented: (#10239 , #10254 )

• solana fees returns a recent blockhash, as well as the last-valid-slot for that blockhash
• solana slot returns the current slot. When current slot > last-valid-slot, the blockhash has expired.

[garious]

Closing this. Only remaining related work is for the RPC node to retry on behalf of the send_transaction caller, but that's tracked in another ticket.