Improve APIs for Tries in Runtime

[shawntabrizi]

This is a refactor and improvement from: #3881

• sp_runtime::proving_trie now exposes a BasicProvingTrie for both base2 and base16.
• APIs for base16 are more focused on single value proofs, also aligning their APIs with the base2 trie
• A ProvingTrie trait is included which wraps both the base2 and base16 trie, and exposes all APIs needed for an end to end scenario.
  • This is important because when writing benchmarks, you need abstractions to be able to create and prove tries of different sizes.

[shawntabrizi]

Overall, the assumption here is that the bytes of the proof are mostly hashes.

Based on how many hashes are there, and the structure of the trie, we can then know how deep the trie is.

For example, if we have a base 2 trie, there should be 1 hash at for every level of the trie. For a base 16 trie, there should be 15 hashes.

Funny enough, for worst case scenario, we need minimum_encoded_len of the types to get a more accurate result.

To get the most accurate result, we also want to remove the key and value bytes and any other extraneous information from the proof size.

If we use MaxEncodedLen, we may overestimate how many bytes are actually being used for the values, and then underestimate the number of hashes we will actually do.

In this case, I assume an even worst case scenario that all bytes are hashes.

[ggwpez]

In this case, I assume an even worst case scenario that all bytes are hashes.

I only read the code and figured that's what's going on. It is a pragmatic solution and i think it should be fine =)

[shawntabrizi]

I made the trait more general, just ProofToHashes.

For Base2 trie, we can look at the number of items directly to get the depth. For Base16, we can still use this length trick.