Remove is_merge_transition_block check since Capella

[hwwhww]

This PR removed the is_merge_transition_block check from Capella on_block:

    if is_merge_transition_block(pre_state, block.body):
        validate_merge_block(block)

At least for mainnet, these checks are useless.

From @mkalinin:

I feel like we can safely remove if is_merge_transition_complete(state): condition from process_execution_payload in Capella unless Bellatrix and Capella are scheduled at the same epoch. In this case this condition must exist otherwise payload.parent_hash check will always fail. But I don't think anyone uses this chain specificaiton for any purposes, because it involves setting up PoW or PoA which ppl might not want to have a deal with.

I fee like the following code can be removed from the fork choice spec disregarding fork schedule as it just validates TTD and TBH which doesn't make sense for mainnet and likely for test/dev nets too.

[terencechain]

Nice! +1 for client code clean up. But also worth checking if this breaks existing Hive or Antithesis tests

[djrtwo]

I'm mixed on the proposal. we don't yet remove it from the state transition function so weird to remove it only in one place

I also could imagine some use for doing a transition at Capella on an alternative network.

That said, I'm not that opposed to this if others want it. Def want to check with @marioevz to see if this will break some hive assumption

[mkalinin]

Though, it would be still possible to do the merge transition at the same time as Deneb, I would consider doing a full clean up of transition logic at that time as introducing blob transactions on EL without execution enabled on CL is odd.

I also could imagine some use for doing a transition at Capella on an alternative network.

They would need to schedule Bellatrix first and then after the transition happens they could schedule Cancun. Also, those networks would need clients supporting transition logic.

[tersec]

This is consistent with simply not ever supporting doing a merge again. That, in itself, I have no objection to: either start unmerged and stay unmerged, or start merged.

However, if merging is supported at all (e.g., insofar as the Bellatrix fork retains such a function), this ensures that merging remains a strangely partly-supported functionality, if and only if one goes back to Bellatrix.

I am not strongly against this, but it conveys a rather muddy conceptual model.