Keymanager API: fix fee recipient API and add persistence

[james-prysm]

What type of PR is this?

Bug fix

What does this PR do? Why is it needed?

This PR address 2 issues.

1. Fee Recipient API did not periodically call the beacon API with the correct data.Keymanager API: Fee Recipient not periodically sending values #11539
2. Fee Recipient values did not persist correctly after validator restarts. The value will now persist after the start of each epoch if updated through the API. if the validator restarts directly after an update before the beacon API is called then the value will not persist on restart. The value set in the validator client will override values in the beacon node on restart, if one does not wish for the value to overwrite the beacon node's values they should not provide the validator client any on startup.

Which issues(s) does this PR fix?

Fixes #11322,#11539

[rkapka]

After the update the log is a bit ungrammatical/incorrect:

The client will periodically signal updated settings such as fee recipient in the beacon node and custom builder

[rkapka]

Why have proposer settings in two places when we can read them from v.validator? This can cause bugs when we update in one place but not the other.

[james-prysm]

this is what caused the original problem, unfortunately...

the runner.go has access to the validator directly but other parts such as the API only has access to the validator service and not the validator inside it... the node service at startup passes the data via config to the validator service into the validator as well ( the validator is only created with the values on validator service start). To try to remediate some of this I made the validator service's proposersettings private and calling the update this way will update both. open to other suggestions on this.