Support multi-hash in multi-trie via PlainDB

[sorpaas]

Requires paritytech/trie#2, solves #872 (comment)

This adds multiple hash algorithm support for multi-trie. See paritytech/trie#2 description for how this will work.

• Ephemeral implements PlainDB traits. PlainDB is HashDB with hashing stripped. Unlike HashDB, PlainDB will not check for null node, and it's expected that wrapper of PlainDB handles that.
• For substrate-trie, hash_db::HashDB/PlainDB are taken into function as generic (instead of trait objects). This change is because Rust does not support super-trait upcasting, but for functions like child_delta_trie_root, we need DB to be HashDB + PlainDB.

[sorpaas]

This looks like can't use the HashDB type alias defined above because Rust treats type alias and traits differently.

[rphmeier]

there has been an RFC for trait aliases for ages but not happening anytime soon sadly. type aliases of traits are actually for the unsized values with the type of the trait.

[sorpaas]

Added two new traits in hash-db: PlainDBRef and HashDBRef. The reason for this is that sometimes we pass down immutable reference of PlainDB, and the user may want to wrap them and create new instance of HashDB. In this case, we need to implement immutable and mutable reference wrapper separately (because there's no generic over reference in Rust). For immutable reference, all the mutable functions still appear in the trait, and if without PlainDBRef and HashDBRef, they would need to be marked as unreachable!(), which is not nice.

[gavofyork]

would be great to get some more eyes on this as it may become relevant for a smart-contract chain with storage-rent.

@svyatonik will this present a big issue for light client and/or change trie?
@arkpar any interactions/significant maintenance burden for client/db?
@rphmeier any other issues?

[svyatonik]

For light client, imo, that wouldn't be a problem iff there'll be some strict correspondence (known to light client) between child storage (identified by storage_key) and the hashing algorithm that it uses. Would be good to see example of how it'll work for full client first, though. Right now I could see that child storage is completely unavailable on light clients. This could be fixed easily (without multi hashing).

Changes trie is a separate trie, which could use its own hashing algorithm (i.e. Blake2 for all child storages). But there's another issue - we need to emit separate DigestItem::ChangesTrieRoot for every child storage in every block if we want they to be covered by changes tries. I'm not sure it is a good idea. Right now changes tries are only covering top-level storage changes - probably we should leave it as is?

[gavofyork]

probably we should leave it as is?

Sounds reasonable, yeah.

@rphmeier @arkpar thoughts?