Persist ProposerData (prepared\registered proposerd) on BN to survive upon restart

[tbenr]

There is a well known condition in which our BN will use default fee recipient. Since we do not persist prepared\registered proposer anywhere, when BN restarts it loses the information and will get it back on next VC poll, which suppose to happen on each epoch (for teku VC is at beginning of third slot). During this time window, if a validator have a block proposal duty, BN will use default fee recipient and will also give less time to EL to produce a payload (we will send FcU with attributes and getPayload in sequence)

An improvement would be to persist prepared\registered proposerd (the data managed by ProposerDataManager) on disk and reload it upon restart.

Another option is to make VC resend info if loses connection with BN (on event stream reconnection?) but this will improve our VC and not make BN by itself more resilient to restarts and so less dependant by VC behaviour.

[ajsutton]

I'd probably go with the VC change as we can't assume the beacon node will persist the data to disk either (the api doesn't require it and I think even mentions it may be forgotten when the beacon node restarts).

[ajsutton]

Going to close this one. We seem to be handling this fine in the real world and other BN implementations don't persist the data either so we can't depend on that anyway.