Parallelize parts of transaction verification and conversion

[nagisa]

Description

When there are a huge number of transactions containing Very Cheap to Process actions in a chunk, we start seeing a significant portion (~35%) of the CPU time being spent in just process_transactions/verify_and_charge_transaction:

• ~20% in signature verification;
• ~14% in reading out account and accesskey data.

In principle the functionality here is structured such that a lot of the work within it is parallelizable, with the only exception being its &mut TrieUpdate argument. Mutable trie access is only necessary at the end of the function to update NEAR balances and the access key nonce and doesn't need to happen at the end of each transaction processing, strictly speaking.

Since all operations operate on data that's sharded by AccountID here, the transactions can be grouped by the signed AccountID first and then any changes to nonces and balances would be applied to the state in one go on the main thread once the processing for a group of transactions is complete.

There are also other approaches that may be considered. For instance, we can validate just the signatures in parallel without any prior grouping and let the remaining work continue on the main thread. The processing time ceiling then would be roughly the 14% we see in reading the account/accesskey data...

[nagisa]

cc @akhi3030 @mooori