Update Shiden Ethereum block hash fix to upstream

[Dinonard]

Description

Revert old block hash fix - Shiden block fix with the upstreamed better fix - polkadot-evm/frontier#1044

In general, as part of this task, we should get rid of the custom dirty fix code we use to circumvent the issue.

What is the block hash fix?

Due to some problem with storage migration back in the day, for few blocks (most likely one) there parent hash is lost and when retrieved via RPC results in 0x00..00 (Default::default()).

More context here:

• Fix bug parent hash on BlockV2 upgrade polkadot-evm/frontier#570
• populate parent hash for indexers polkadot-evm/frontier#1044

Question/issue in upstream frontier: polkadot-evm/frontier#1534

[Dinonard]

We should try&do this, and check if Shiden can be synced from the scratch.

This doesn't impact Astar in any way.

[ashutoshvarma]

The upstream solution is designed to hardcode the parent hash for few blocks. This issue with Shiden is more than that as we need to tackle for all the blocks prior to EVM Upgrade (upgrade block 339070, applied block - 339330).

So upstream solution is not for us unfortunately as it will solve the polkadot-evm/frontier#570 for 1-2 blocks impacted but not for blocks prior to 339330

(book keeping - frontier shiden fix original commit here, Astar PR - #532, Astar Issue - #521)

[Dinonard]

That's unfortunate.
However, even if we cannot reuse this solution, it doesn't mean we cannot attempt to resolve this in the frontier.

I'm not exactly sure what the proper fix for this would even be if pallet is introduced while chain has been live for some time already. Maybe None is perfectly legit to have, and indexers should have just skipped blocks until our Ethereum chain starts.

That being said, why not try and merge this as a solution upstream?
It could be configurable behavior (to avoid impacting any other chains out there).