Error in VC when fee recipient is only set in the BN

[realbigsean]

Description

This was brought up in Discord: in the VC we log an error if the fee recipient isn't set in the VC. But it could be set with the BN's fee recipient flag.

https://github.com/sigp/lighthouse/blob/stable/validator_client/src/preparation_service.rs#L273

We have to decide whether it should be possible for the BN's fee recipient to be used as the primary configuration. If we decide yes, we should make it possible to suppress the VC error, otherwise it seems fine to keep.

The only way I can think of to suppress the error is to add a flag to the VC, something like --use-bn-fee-recipient. But because there's no way to verify the BN actually has a fee recipient configured, it might be too dangerous a flag to add on its own.

We could potentially make an issue on the beacon APIs repo to add a GET beacon_proposer_details endpoint or something similar. And just check this endpoint if there's nothing configured in the VC.

[michaelsproul]

I think this will cause blocks with 0 transactions to be proposed, because the beacon node will skip sending proposer preparation messages when it doesn't have any proposer preparation data, see:

https://github.com/sigp/lighthouse/blob/c2604c47d6d286728f36563bb503a7a0d4a7bf57/beacon_node/beacon_chain/src/beacon_chain.rs#L3717-L3721

And the VC avoids sending any proposer preparation data when it can't find a fee recipient:

https://github.com/sigp/lighthouse/blob/df51a73272489fe154bd10995c96199062b6c3f7/validator_client/src/preparation_service.rs#L263-L284

As a temporary workaround for v3.0.0 I think we should recommend setting the fee recipient in the VC and not solely in the BN.

[realbigsean]

We'd still get a chance to include transactions in the fallback here: https://github.com/sigp/lighthouse/blob/stable/beacon_node/execution_layer/src/lib.rs#L799

But this lack of delay between fcu and getPayload causes issues for some EE's so it's not good that we'd consistently get here.. so the ERROR seems like a good thing in potentially dissuading users from only configuring fee recipient in the BN, but the question still remains whether we should fully support BN-only fee recipient config or not. A --use-bn-fee-recipient could have the effect of always sending proposal prep data as well.