feat: add canonical cache for live sync

[forcodedancing]

Description

Add cache layer to cache historical committed accounts & storages.

Rationale

To improve the execution of live sync.

Example

Test Result - Live sync 20K blocks on BSC, from 41413200 to 41433100.

Note: There are reboots before each tests, to make sure the test environment is clean.

• Metrics 1 - hit rate

account hit rate (the l3 account in the figure): 36.2%

storage hit rate (the l3 storage in the figure): 43.3%

Note: l1 account & storage caches refer to the revm state cache.

• Metrics 2 - the execution time for every 100 blocks

The time decreases about 21% after steady. (due to reboot, at the beginning, the performance is bad for both).

The time to apply bundle state to cache (update cache after db commit) is included for the cached version.

• Metrics 3 - the gas throughput for [41432701, 41433100]

The cached version is 356 Mgas/s for execution on avg, while the original version is 277 Mgas/s.

The gas throughput increases about 28%. Why it is not aligned to the execution time?

• The avg Mgas/s is calculated from the log (each block has a log about it).
• The cached version introduces some extra cost for applying state to cache. This extra time is included in the Metrics 2.

Changes

Notable changes:

• add each change in a bullet point here
• ...

Potential Impacts

• add potential impacts for other components here
• ...

[unclezoro]

storage.wipe_storage seems only mean to the storage of an account, but why we clean all storage cache here?

[forcodedancing]

The reason is that: the quick cache is very simple there is no function for iterate or find keys with a prefix.
One way is that we can make storage cache to use nested structure, e.g., a map or another layer of cache. However, it seems a bit complex. Do you think should we implement in this way?

[unclezoro]

I think we should have some test, like create/destroy a contract to ensure our cache works well