cli: Simulate for compute units consumed during transfer

[joncinque]

Problem

As part of the ongoing work to properly size transactions, as in #1810, the CLI still isn't simulating the transaction in most cases to find out the compute units consumed, causing users to pay too much in fees when a compute unit price is set.

Summary of Changes

This PR focuses on the resolve_spend_message case, which can also support the ALL keyword. To simulate the transaction only once and fetch the right fee, the message is modified similarly to this program deployment logic:

agave/cli/src/program.rs

Lines 2949 to 2963 in 51af772

	if let UpdateComputeUnitLimitResult::UpdatedInstructionIndex(ix_index) =
	simulate_and_update_compute_unit_limit(&rpc_client, &mut message)?
	{
	for msg in &mut write_messages {
	// Write messages are all assumed to be identical except
	// the program data being written. But just in case that
	// assumption is broken, assert that we are only ever
	// changing the instruction data for a compute budget
	// instruction.
	assert_eq!(msg.program_id(ix_index), Some(&compute_budget::id()));
	msg.instructions[ix_index]
	.data
	.clone_from(&message.instructions[ix_index].data);
	}
	}

The only actual change to behavior is for solana transfer -- the rest will be done in smaller PRs which look just like the last two commits of this PR.

Fixes #

[jstarry]

Why don't you simulate nonce transactions?

[joncinque]

(Sorry for the late response, I was out for a bit)

We took this approach with the token CLI in solana-labs/solana-program-library#6550 to handle offline signers. Since offline signers can't access the network, we can't simulate the transaction before signing, so they'll need to use the default (or eventually static) compute unit limit.

When broadcasting the signed transaction, we need to create exactly the same transaction as the offline signers, so we use the presence of a nonce account as a guess that there are offline signers, since we can't tell from a Signer if it's a pre-signer.

While offline signers and nonces aren't directly related, I couldn't come up with another easy way of knowing if a transaction has pre-signers. Suggestions are very welcome!

[jstarry]

Sorry for the delay.. So the situation you describing is broadcasting an already signed transaction where all signers are pre-signers and we almost certainly used a nonce for creating the transaction? And the assumption is that if you're using a nonce it also generally means that this is probably an offline transaction in which you are using pre-signers?

Since the CLI knows whether pre-signers are being used and whether a blockhash was supplied explicitly, we can use those signals to decide whether to simulate or fall back to default. What do you think?

[joncinque]

Yeah pretty much, the situation is more specifically if any of the signers was a pre-signer, in which case there's a high probability that it was signed offline.

The main reason that I resisted that approach is that the --signer or --blockhash args are parsed by helpers like signer_from_path and BlockhashQuery, and the top-level normally never references them directly. But you're right, those are probably clearer than just the presence of a nonce account.

If we do go with that approach, we already have the BlockhashQuery and can disable the simulation if it's None or FeeCalculator. For the pre-signers, we need to add another field to all of the command parsers, like contains_presigners, and just check if the --signer arg is present. What do you think?

[jstarry]

Hmm after thinking more I think the nonce account approach is a good enough signal for now. The offline signer / supplied blockhash signals are technically not perfect either. Makes me feel all of that could be cleaned up in a separate change but for now this approach is fine.