Revert "Handle staking info since kaia fork in downloader."

[hyeonLewis]

Reverts #2160

Initially, I mis-interpreted the testing results so I merged it. Sorry for the confusion.

During several snap sync tests, it was found that #2160 can't solve the block header verification issue correctly. The block header initially comes to processHeaders, which inserts the header into the header chain first. Then, the contents for fetched headers will be scheduled by Schedule, which includes staking info. So, the staking info needs to be fetched with headers and ready before insertHeaderChain. But the current implementation fetches staking info after insertHeaderChain, which means it does nothing. (It worked before kaia fork since it required staking info before staking update interval)

Additionally, it seems that randao also breaks snap sync since it requires state at a block to retrieve the BLS registry. https://github.com/klaytn/klaytn/blob/dev/consensus/istanbul/backend/randao.go#L63

To sum up, I concluded it would be better to consider all the cases carefully to fix the snap sync. If you have suggestions, please let me know. Thanks.

[blukat29]

I'm okay with turning off the snapsync again. It was our first plan wasn't it?
Let's sit back and try other solutions over time. Such as skipping header verification for the pivot block? which would require additional argument all the way through headerchain though.

[hyeonLewis]

@blukat29 Thanks for your comment. Yes, disabling snap sync was our first plan.

We actually need to skip all the blocks inserted via insertHeaderChain, not only pivot block. So I think we have two options:

1. Skip verifying headers, and verify it after fetching staking info.
2. Adjust fetching timing of staking info after Kaia fork.

As I mentioned, we must include the bls registry (+ temporal DB for BLS registry) fetcher.