Combine account locking and block space reserving in single loop

[tao-stones]

Problem

Transaction takes up block space before acquiring accounts lock, if it fails getting lock, block space is not immediately released.

Summary of Changes

• release reserved block space immediately after lock acquisition
• replace transaction's cached cost with account lock error if block space released, this is to prevent possibility of double-removing its costs.

Fixes #34825

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8ff511e) 81.6% compared to head (7c3941c) 81.6%.
Report is 178 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #34909     +/-   ##
=========================================
- Coverage    81.6%    81.6%   -0.1%     
=========================================
  Files         827      827             
  Lines      223884   223941     +57     
=========================================
+ Hits       182841   182876     +35     
- Misses      41043    41065     +22     

[apfitzge]

we don't need to allocate a new vec here, we can just iterate over our qos and lock result pairs...something like

        // Remove reserved block space for transaction failed to acquire lock
        let mut cost_tracker = bank.write_cost_tracker().unwrap();
        transaction_qos_cost_results
            .iter_mut()
            .zip(batch.lock_results())
            .filter_map(|(qos_cost_result, lock_result)| {
                match (qos_cost_result.as_ref(), lock_result) {
                    (Ok(_), Err(lock_err)) => Some((qos_cost_result, lock_err)),
                    _ => None,
                }
            })
            .for_each(|(qos_cost_result, lock_err)| {
                cost_tracker.remove(qos_cost_result.as_ref().unwrap());
                *qos_cost_result = Err(lock_err.clone());
            });

[tao-stones]

TIL! I was having trouble to change qos_cost_result while it is borrowed by match (i think).

Before making the change tho, are we good with this approach, or would like to "lock-reserve-unlock" you mentioned elsewhere?

[apfitzge]

as an alternative to mutability here. we could also use the lock-results to inform the cost-adjustment post-execution. Not sure if that would be cleaner though.

[willhickey]

This repository is no longer in use. Please re-open this pull request in the agave repo: https://github.com/anza-xyz/agave