VC to delay before switching back to recovered beacon node

[paulhauner]

Description

As per this thread, it seems to make sense to delay switching back to a BN after it comes back online (e.g., if primary was offline but came back online). This allows the BN to get itself in order and acts as a bit of a "debounce".

I propose a 2-3 epoch delay.

[lfinbob]

I had a disappointing fallback experience today where this would have helped:
My lighthouse validator is connected to 2 different lighthouse beacon nodes.
The primary one is on the same machine, the other is remote.
Then, on the primary machine I changed my beacon node's p2p port and restarted it.
It had 0 (or low) peers for ~15 minutes, because I was slow to update my firewall rules.
During that time my validator happily sent attestations to the low-peer beacon node instead of the 100-peer beacon node and I missed 3 attestations in a row.

[macladson]

Since the merging of #4393, we now have more sophisticated fallback behaviour. While this behaviour does not include a debounce, it should not switch back to a disconnected node until it is synced close to the head (default is within 8 slots) which should help this particular issue. So I will close this for now, and if fallback issues continue to be widespread, new issues should be opened.