[Perf] Cache fee verification

[vicsn]

Motivation

When processing hundreds of transmissions during block generation, transaction verification is a large bottleneck, taking up 90% of compute. Half of that is spent verifying the SNARK proofs associated to fees. We should cache that.

Some useful details:

• Despite changing caching logic, this does not require a migration because the cache is in memory and will be cleared on a necessary upgrade restart.
• There are 3 cases for the fee: its from a Deployment, Execution, or Fee transaction. Given that Fee transactions are only created during block generation and are only verified once, it is technically superfluous to add those to the cache. But its cleaner at negligible cost.
• Since the PR which introduced the cache, I realize we can cache potentially way more checks, but the SNARK verification is by far the largest cost anyway, so we can stick with the existing setup.

Test Plan

• Added cache state expectations to unit tests. Fee tests are not in there because the respective test-helper doesn't expose the rejected id.
• Ran succesfully on deployed network

Related PRs

• Cache was introduced in: Cache transaction checks #2270
• Importance of caching highlighted here: [Perf] Greedily verify Executions before block generation snarkOS#3451

[raychu86]

Logic overall LGTM! I don't recall why we didn't do the fee cacheing before when we had initially introduced it.

One thing I would ask you to think about as the author of the PR is the following:

Fee's can be swapped between transactions and Executions/Deployments can be broadcasted with different Fee transitions. Does this PR cover those cases? (I think it does, but want to be doubly sure)