Fork choice changes for confirmation rule

[paulhauner]

Description

There is a likely-to-be-merged proposal which makes a minor modification to fork choice:

ethereum/consensus-specs#3431

The change itself should be rather simple to implement. It's a small, isolated change which doesn't affect any persisted data (i.e., no database migration required).

There is some more complication in how we activate the changes (discussed in ethereum/consensus-specs#3466). There are two options:

1. "Loosely coordinated": We simply replace the old logic with the new logic and then try and release around the same time as other clients. The network will be inconsistent for some weeks, however it's unlikely to be an issue.
2. "Tightly coordinated": We keep the old and new logic around and switch from the old logic to the new logic at some epoch.

As of writing, there's no decision as to which route the clients will take.

If we take the (2) route we'll need to do some thinking to ensure that we don't end up with a mix of logic and an inconsistent state.

Update

It seems that the consensus is to go ahead with option (1): #4566 (comment)

[jimmygchen]

Hey Paul, thanks for the write up! I'm interested in working on this one.

[realbigsean]

On ACDC, it sounded like there was a preference for 1, and to include this in the deneb release

[michaelsproul]

Implemented in #5094