Force the proposer to reorg late payloads

[potuz]

Requires #5186

This makes the proposer reorg late payloads.

⚠️ We may want to add the conditions of the current honest reorg features to this PR, that is, we may want to short circuit this when the chain is not finalizing, when the head is not from the previous slot, etc. Leaving this as a placeholder until a decision is made on 5186 to revisit here.

[jtraglia]

@potuz please give this PR a better title & run make lint.

[tbenr]

what are the interactions with get_proposer_head?
I mean: if we do a full beacon block reorg, should we apply should_build_on_full on top of parent as well?
So can we be in a situation that we will build on top of parent's EMPTY, essentially reorging 2 payloads?

[potuz]

what are the interactions with get_proposer_head? I mean: if we do a full beacon block reorg, should we apply should_build_on_full on top of parent as well? So can we be in a situation that we will build on top of parent's EMPTY, essentially reorging 2 payloads?

I would rather not make get_proposer_head a mandatory specified thing so I did not want to make it explicit here. One argument to always apply it is that it is rational to do so and so we may see forks that do so. Another would be to also punish the builder in the case that a consensus client struggling to execute a late payload that sends its CL block late because of this and is therefore reorged (admittedly a stretch/bug).

Arguments to not use this would be to restrict to one payload reorgs instead of two.

At any rate I wouldn't want to be mentioning get_proposer_head here and would rather leave that to implementers instead. Neither type of reorgs can be enforced either way because attesters will anyway follow the proposer.

[tbenr]

I'm leaning to apply it no matter what, which is what is in our current PR (which triggered me on the question).
It makes total sense to do what you would have done if you were the proposer of reorged beacon block (which is weak by definition).

[nflaig]

assuming we merge #5309, this looks good to me

[jtraglia]

LGTM & makes sense. I feel like the get_proposer_head question is resolved or no longer relevant, but if for whatever reason that is not true, we can follow up later with tweaks.