Fix bug parent hash on BlockV2 upgrade

[tgmichel]

This bug can be reproduced after storage upgrade from BlockV0 to BlockV2, and only if the preceding block contained transactions. In that case the current_block_hash function will try to decode BlockV2, failing to do so because the block contains TransactionV0s and returning None, defaulting to H256::default(), rendering the parent hash useless and of course messing the block hashing of the subsequent blocks.

This PR proposes just use the already existing BlockHash storage and query it using the previous block number.

This is a pretty nasty bug and should merged in asap @sorpaas . Also, do you have any suggestion on how to test this type of situation in frontier?

[sorpaas]

This is a pretty nasty bug and should merged in asap

The current PR changes the meaning of parent hash though. For the majority of Ethereum dapps, it just shouldn't matter at all, and we can set the parent hash to even H256::default() without any issues. However, for anything that does matter, this break things -- the parent hash is supposed to be used to be able to fetch the parent Ethereum block (encoded by the Ethereum block hash, not Substrate block hash).

I'd prefer you change this PR to a runtime migration (decode BlockV0 and write BlockV2 for CurrentBlock on runtime upgrade).

Also, do you have any suggestion on how to test this type of situation in frontier?

This bug could have been detected if Substrate wasn't silently failing on those should-be-panic cases. It's essentially a migration bug. With above we could have prevented it together with try-runtime (which should print the fail-to-decode error). The primitive for the "defensive infallible" are already merged in paritytech/substrate#10626, but it still has to be integrated in frame's decoding code path.

[tgmichel]

I agree that runtime migration is preferable. @sorpaas for visibility, as we talked:

However, for anything that does matter, this break things -- the parent hash is supposed to be used to be able to fetch the parent Ethereum block (encoded by the Ethereum block hash, not Substrate block hash)

That's not the case, as BlockHash is Ethereum block hash, not the Substrate one.

[tgmichel]

@sorpaas added the migration functions. I still think reading BlockHash storage is an improvement over performing the keccak on-the-fly so I still include that change, but please let me know.

[sorpaas]

Please pull master.