VC should publish proposer preparation and validator registrations to all connected BNs

[michaelsproul]

Description

Validator clients using fallback beacon nodes may miss out on quality block proposals in some situations because they don't send proposer preparation and validator registration messages to any beacon node except the primary. If the primary fails before these messages are re-sent, then a fallback BN which lacks the preparations and registrations will be used instead, likely resulting in a block with 0 transactions, as the BN sends forkchoiceUpdated

This issue is mostly addressed by #3529, which broadcasts the proposer preparation messages. However it does not (presently) broadcast the validator registrations. This may be less of an issue, as the builder(s) probably remember the registrations from the primary beacon node.

CC @realbigsean @pawanjay176

[realbigsean]

Yes, definitely need the changes in #3529!

For registrations, I imagine people using fallback BN's with builders would usually either have:

1. Both BN's connected to the same set of relays, so broadcasting registrations would end up doubling the load of messages relays have to process
2. Only the primary BN has a builder configured, assuming if we are on our fallback node we should be as conservative as possible. Here a broadcast wouldn't be beneficial and would just produce some ERRO's

I think generally registrations are sent with enough frequency and that relays cache them for long enough that we're OK to just send them to the first successful node.

[pawanjay176]

I agree that registrations don't need to be sent to every beacon node for now, can add it later on if really required.

[michaelsproul]

Awesome I'll mark this as closed by #3529 and we can re-open if we see issues with registrations