rpc: fix possible deadlock in rpc

[BurtonQin]

Problem

There is a possible deadlock caused by double readlock in fn get_transaction_status.

block_commitment_cache is an Arc<RwLock<...>>.

The first readlock is on L1434

solana/rpc/src/rpc.rs

Lines 1434 to 1436 in fbf7143

	let r_block_commitment_cache = self.block_commitment_cache.read().unwrap();
	let optimistically_confirmed_bank = self.bank(Some(CommitmentConfig::confirmed()));

The second readlock is on L253 in fn bank

solana/rpc/src/rpc.rs

Lines 250 to 254 in fbf7143

	let slot = self
	.block_commitment_cache
	.read()
	.unwrap()
	.slot_with_commitment(commitment.commitment);

For more details on this kind of deadlock, see
https://www.reddit.com/r/rust/comments/urnqz8/different_behaviors_of_recursive_read_locks_in/

Summary of Changes

The fix is to move the first readlock after the calling of fn bank.
But I wonder if this is correct or optimal.

1. I do not know if optimistically_confirmed should be protected by block_commitment_cache? OR
2. can we drop r_block_commitment_cache immediately after the creation of confirmations on L1440-1448.

Fixes #

[codecov]

Codecov Report

Merging #26051 (97cc753) into master (8caced6) will decrease coverage by 0.2%.
The diff coverage is 75.0%.

@@            Coverage Diff            @@
##           master   #26051     +/-   ##
=========================================
- Coverage    82.1%    81.8%   -0.3%     
=========================================
  Files         628      631      +3     
  Lines      171471   174123   +2652     
=========================================
+ Hits       140878   142595   +1717     
- Misses      30593    31528    +935     

[CriesofCarrots]

@BurtonQin , to be clear, there is only a risk of deadlock with write-prioritized RwLocks, correct?

[BurtonQin]

@BurtonQin , to be clear, there is only a risk of deadlock with write-prioritized RwLocks, correct?

Yes.

[CriesofCarrots]

Thanks for the contribution