Recording partial trie for storage proofs

[mikhailOK]

Record every read of a trie node from storage to use
the recorded values for a proof of execution.

This includes all key paths for keys requested for reads, but also
in case of updates can include additional nodes which are
necessary to provide a canonical resulting trie (i.e. no branch nodes
with <= 1 branch and extension is always followed by a branch).

[MaksymZavershynskyi]

Should merge into staging instead of master.

[MaksymZavershynskyi]

I think for poisoned locks it makes sense to just unwrap. If lock is poisoned the program will fail with verbose message anyway.

[mikhailOK]

We have this pattern everywhere, it's for readability I think

[MaksymZavershynskyi]

I asked to introduce this pattern before. However, now I realized the following:

• If the Error that we are unwrapping implements Debug the result of calling unwrap on it will be panic with that error message printed.
• If we say expect("some custom error message") then the result is panic with the custom error message printed.

So unless there is any additional information to say, besides the fact that "lock is poisoned" there is no real reason to use expect since unwrap will have the same effect.

[mikhailOK]

It's a code readability pattern - expect() with an explanation that it can never fail or that it's impossible to recover from the error. More explicit than unwrap()

[MaksymZavershynskyi]

unwrap() implies exactly the same semantics. Anywhere in the code if you see unwrap it implies that this should never fail. Are you saying the word unwrap is less descriptive than the word expect?

[mikhailOK]

let mut guard = self.cache.lock().expect(POISONED_LOCK_ERR);
or
let mut guard = self.cache.lock().unwrap(); // the only possible failure is poisoned lock

[MaksymZavershynskyi]

Let us know when to review again.