Zero-allocation Trie/HashDB lookups

[rphmeier]

Driven by a

fn get_with<F, T>(&self, key: &[u8], f: F) -> Option<T> where F: FnOnce(&[u8]) -> T;
fn get(&self, key: &[u8]) -> Option<Bytes> { self.get_with(key, |b| b.to_vec()) }

or similar alteration to each API (slightly more complex in the presence of trie lookup errors/recorders).
In the state/account modules we can use this to decode values out of the trie immediately without a prior alloc/copy.
In trie lookups we can recursively decode nodes until we find the one with the desired value and then call the provided closure.

[rphmeier]

While any lookups which go to RocksDB will still end up allocating, anything in the pruning overlay or kvdb working set actually will be fully zero-alloc. A smarter (read: non-cloning) cache in kvdb instead of rocksdb will make this even more effective for ArchiveDB which doesn't keep much around.

[rphmeier]

Taken a look into this for now, it seems that it'll be more difficult than anticipated for HashDB for a few reasons:

• HashDB is typically used as a trait object and generic functions aren't object safe.
• get_with for HashDB can't be re-entrant because implementations would typically call the closure while holding a read-lock on a cache of some kind which could lead to deadlock.

On the plus side, the TrieDB changes have been pretty simple to make. The rest will come a bit later with a more generic client and separation of JournalDB/HashDB via an associated type.

[5chdn]

This optimization labelled issue is inactive since last year.

@paritytech/core-devs Please, confirm within 7 days if this is still relevant. If so, please comment below and add an assignee, or close it otherwise.

[rphmeier]

Still relevant, but halfway taken care of.

[folsen]

Closing because it seems of questionable value given @Vurich's closed PR and the difficulty in actually doing this. Would consider reopening if a profiler said this was a big bottleneck.