Trie/Client: Add permanent Trie Node Cache + Client Integration

[holgerd77]

This PR adds a permanent Node cache to the Trie checkpoint DB class which increases client block execution in particular and repetitive trie reads in general.

Cache design is extremely simple since trie node keys are unique, so there is no need for this back-and-forth related to checkpointing, since there is no risk to overwrite and old entry and therefore accidentally introduce a wrong key. I tested this with longer client sync ranges and there were no problems.

It is also "by design" that reverted node entries are kept in the cache, since this might help to mitigate repeated revert-attacks with the same attack setup, always re-reading the same accounts/slots e.g. and then revert.

I in-between planned to activate this LRU cache by default, since in most cases there should be no downsides. I then discovered several ad-hoc Trie instantiations in our own code base (mostly related to proofs), so I restrained since there might be side effects if regarding too frequent instantiations.

(Side question: do these Proof methods need any Trie object state or might it generally be an option (respectively occasion now during breaking period) to make these methods static?)

Another note: I first added an active cache to the Trie checkpointing tests and these were actually failing. I then had a closer look and realized that these were just creating "un-realistic" trie scenarios - by directly operating on the db and then adding a key and updating the same key with a different value. This scenario can - by Merkle Patricia Tree design - just not happen, since keys are always unique (in relation to the content/subtree they refer to). I already thought if these tests should generally be deleted, but refrained since they do test the general DB functionality nevertheless. All other tests (which I ran in between with the Trie-cache-active-by-default work state) are passing with the cache though.

Open for review and merge.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (develop-v7@cda9043). Click here to learn what that means.
The diff coverage is n/a.

Additional details and impacted files

Flag	Coverage Δ
block	90.64% <0.00%> (?)
blockchain	90.45% <0.00%> (?)
client	87.04% <0.00%> (?)
common	95.76% <0.00%> (?)
devp2p	91.89% <0.00%> (?)
ethash	∅ <0.00%> (?)
rlp	∅ <0.00%> (?)
statemanager	88.19% <0.00%> (?)
trie	89.97% <0.00%> (?)
tx	95.45% <0.00%> (?)
util	81.50% <0.00%> (?)
vm	84.39% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[acolytec3]

Looks good over all. Left a couple of comments we should consider addressing.

[acolytec3]

Looks great pending CI passing.

[jochem-brouwer]

LGTM