Verify terminal PoW block after call to state_transition

[mkalinin]

What's done?

Switches the order of terminal PoW block verification and the state_transition call in the on_block handler of the fork choice.

This change has the following implications:

• During the state_transition call either all dependencies of the execution payload must be resolved (meaning that ancestors of the execution payload must be pulled from the network and processed) or the block processing is delayed
• After the state_transition call, when the terminal PoW block verification reached all the ancestors of the execution payload must be deemed as valid, otherwise, the state transition function would deem the beacon block as invalid
• Consensus clients rely on an execution client pulling the data from the wire and processing the ancestors of the execution payload as a part of serving the engine_executePayload method
• It simplifies the spec and implementations in the following way:
  • there is no need to take into account is_processed and is_valid statuses of the PoW block
  • eth_getBlockByHash JSON-RPC call is sufficiently enough to get the PoW block data, no need to implement extra method
  • no delay in requesting the PoW blocks information is expected other than the delay related to the request/response roundtrip of the JSON-RPC
• There is a risk of wasting time to process a block (including the execution) that is invalid wrt transition process. The risk in the case if such a block appears has low probability and low impact on the system as this block will likely be either invalidated or not processed in time which both leads to a skipped slot which would also be the case before the introduction of this change

Thanks to @djrtwo and @MicahZoltu for the idea of this change

[djrtwo]

excellent!