re-iterator version of SIMD-170 impl

[tao-stones]

Problem

SIMD-170

Summary of Changes

Fixes #

[jstarry]

This approach looks cleaner to me. It does mean that we will do the re-iteration each time we call sanitize_and_convert_to_compute_budget_limits which is not very ideal but I think it can be acceptable.

We call that function in banking stage quite a few times:

• ImmutableDeserializedPacket::new
• SanitizedTransactionReceiveAndBuffer::buffer_packets (called twice, one is hidden in calculate_priority_and_cost)
• Consumer::check_fee_payer_unlocked
• Consumer::process_and_record_transactions_with_pre_results (in QosService::select_and_accumulate_transaction_costs)
• Consumer::execute_and_commit_transactions_locked

It's called during replay during rebatching

• rebatch_and_execute_batches (in CostModel::calculate_cost)

And called for both banking / replay in:

• TransactionBatchProcessor::validate_transaction_fee_payer
• PrioritizationFeeCache::update

[jstarry]

we could eliminate the Clone by changing this function to something like:

pub fn process_compute_budget_instructions<'a, F, I>(
    get_instructions: F,
    feature_set: &FeatureSet,
) -> Result<ComputeBudgetLimits, TransactionError>
where
    F: Fn() -> I,
    I: Iterator<Item = (&'a Pubkey, SVMInstruction<'a>)>,
{

[tao-stones]

Thank you for the list. tbh I am not confident the re-iteration per call will be OK, it kinda negates the purpose of static meta; the lookup at AhashMap when calling BUILTIN_INSTRUCTION_COSTS.contains_key(program_id) can add up quickly. This approach might be slightly better for backporting than tao-stones@86fcaeb; But I still lean to doing heavy lifting in try_from() cause it's called once per transaction, leaving sanitize_and_convert_to_compute_budget_limits() as lightweight as possible (just few if...else and some math).