Implement the /eth/v1/validator/beacon_committee_selections Beacon API end-point

[zah]

Also /eth/v1/validator/sync_committee_selections.

More details are present here:
ethereum/beacon-APIs#224

[tersec]

https://github.com/ethereum/beacon-APIs/blob/f087fbf2764e657578a6c29bdf0261b36ee8db1e/apis/validator/beacon_committee_selections.yaml

Consensus clients need not support this endpoint and may return a 501.

https://github.com/ethereum/beacon-APIs/blob/f087fbf2764e657578a6c29bdf0261b36ee8db1e/apis/validator/sync_committee_selections.yaml

Consensus clients need not support this endpoint and may return a 501.

https://docs.google.com/document/d/1q9jOTPcYQa-3L8luRvQJ-M0eegtba4Nmon3dpO79TMk/mobilebasic

What to implement?
The changes are only on a validator client. Any support or acknowledgement of these API endpoints on the consensus layer side are nominal (return 400 or 501) instead of 404.

ethereum/beacon-APIs#224

This endpoint need not be implemented on the CL side. Once a validator client is aware of it and able to use it when a feature flag is turned on, the intercepting middleware can handle and swallow the request. I suggest a CL either returns:

• 501 Not Implemented
• 400 Bad Request. To indicate to the user that they either have --distributed turned on for a non DV use case, or they have a distributed validator private key wired directly to a consensus client without any middleware in between.

So I guess that's clear enough on the BN side.

[zah]

The remaining work is to teach our validator client to consume these end-points, so it's compatible with the Charon middleware.

[xenowits]

Awesome progress here 🙏. Can someone please add me as a reviewer for PRs for this ticket? It'd be helpful for me track the changes and comment if something's off.

Also, I believe the changes on the validator client are still in progress and so far the endpoints are implemented as 501s only on the beacon client side?

cc: @tersec

[tersec]

#5375