[Storage] Optimize memory cache key creation and key format for some stores

[fxamacker]

Updates #7242

This speeds up key creation by ~372x and eliminates all memory allocs (used by key creation) for some stores. It also optimizes the cache key format to be smaller.

I found this "low-hanging fruit" optimization last week while working on a bugfix PR:

• [Storage] Fix memory caches getting out of sync with databases (BadgerDB and Pebble) #7324

Previously, memory cache key format for transaction results was inefficient and creates needless allocations by encoding to hex. Same issue exists for transaction result index cache and block cache. Light transaction results used by AN also use the same cache key format.

This PR optimizes cache key format for multiple stores:

• cache key format:
  • old: hex(blockID) + hex(txID)
  • new: blockID + txID
• index cache key format:
  • old hex(blockID) + hex(txIndex)
  • new blockID + txIndex
• block cache key format:
  • old hex(blockID)
  • new blockID

Updated stores include:

• TransactionResults
• TransactionResultErrorMessages
• LightTransactionResults

Since cache keys are created for every read or insert of transaction results, etc., it is good to reduce memory allocs when it doesn't sacrifice speed.

Benchmark stats for creating cache key:

                                               │    old.log    │               new.log               │
                                               │    sec/op     │   sec/op     vs base                │
TransactionResultCacheKey/_create_cache_key-12   882.000n ± 8%   2.368n ± 0%  -99.73% (p=0.000 n=10)

                                               │  old.log   │              new.log              │
                                               │    B/op    │   B/op    vs base                 │
TransactionResultCacheKey/_create_cache_key-12   576.0 ± 0%   0.0 ± 0%  -100.00% (p=0.000 n=10)

                                               │  old.log   │               new.log               │
                                               │ allocs/op  │ allocs/op   vs base                 │
TransactionResultCacheKey/_create_cache_key-12   9.000 ± 0%   0.000 ± 0%  -100.00% (p=0.000 n=10)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 92.39130% with 7 lines in your changes missing coverage. Please review.

Project coverage is 41.11%. Comparing base (926dbc0) to head (a32426a).

Files with missing lines	Patch %	Lines
storage/store/transaction_results.go	89.47%	3 Missing and 1 partial ⚠️
storage/store/light_transaction_results.go	85.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #7391   +/-   ##
=======================================
  Coverage   41.10%   41.11%           
=======================================
  Files        2207     2207           
  Lines      193498   193436   -62     
=======================================
- Hits        79544    79532   -12     
+ Misses     107325   107290   -35     
+ Partials     6629     6614   -15     

Flag	Coverage Δ
unittests	41.11% <92.39%> (+<0.01%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zhangchiqing]

Nice optimization 👍 Thanks Faye.