cache multiasset

[kderme]

Optimizations mentioned in #1065
Wip because we want #1058 first

This caches the MultiAssetId in memory to avoid unnecessary queries. The create multiasssets. benchmark which focuses on crteating multiassets outputs, shows a remarkable speedup.
without caching:

benchmarking cardano-chain/bench/create multiasssets./1 block
mean                 986.6 ms   (948.8 ms .. 1.023 s)
std dev              63.15 ms   (0.0 s .. 63.91 ms)

benchmarking cardano-chain/bench/create multiasssets./10 blocks
mean                 8.438 s    (8.185 s .. 8.581 s)
std dev              224.6 ms   (0.0 s .. 248.2 ms)

benchmarking cardano-chain/bench/create multiasssets./100 blocks
mean                 113.5 s    (113.5 s .. 113.5 s)
std dev              0.0 s      (0.0 s .. 0.0 s)

with caching:

benchmarking cardano-chain/bench/create multiasssets./1 block
mean                 525.4 ms   (524.1 ms .. 526.3 ms)
std dev              1.286 ms   (0.0 s .. 1.476 ms)

benchmarking cardano-chain/bench/create multiasssets./10 blocks
mean                 2.784 s    (2.711 s .. 2.820 s)
std dev              63.34 ms   (0.0 s .. 65.33 ms)

benchmarking cardano-chain/bench/create multiasssets./100 blocks
mean                 25.71 s    (25.71 s .. 25.71 s)
std dev              0.0 s      (0.0 s .. 0.0 s)

This benchmark creates 7000 ma_tx_out entries per block, for 1, 10 and 100 blocks. All ma_tx_out created (700000 in the 100 blocks benchmark) reference 700 distinct multiassets.

Mainnet has hundrends of millions of ma_tx_out entries, so I expect some noticeable speedup there. This remains to be checked.

Caching can be improved with a LRU cache using https://hackage.haskell.org/package/psqueues to avoid using too much memory for caching all entries.

[erikd]

Why are we using (ByteString, AssetName) tuple there instead of just using the asset fingerprint?

[kderme]

The fingerprint needs to be computed by hashing these two, so it takes some time.

[kderme]

A more general caching approach is here #1074

[erikd]

PR #1094 has been merged and it supercedes #1074 .