Fix race condition between validator duties service and proposer preferences

[eserilev]

Issue Addressed

The proposer preferences service was attempting to publish preferences at the start of each epoch. This caused it to race with the validator duties service, it wouldn't calculate validator duties in time for the proposer preference service.

This PR first updates the validator duties service to calculate proposer duties for the current epoch and the next epoch. After Fulu we have the ability to look ahead one epoch for proposer duties, but we never updated the vc to leverage this feature.

This PR also updates the proposer preferences service to fire at every slot. We have an (Epoch, DependentRoot) map that prevents us from publishing the same preferences twice.

The changes here should prevent the race condition between the two services and make the proposer preferences service more robust in general.

[mergify]

Some required checks have failed. Could you please take a look @eserilev? 🙏

[michaelsproul]

Ideally we should use get_validator_duties_proposer_v2 here to avoid the issues with the dependent root in the v1 API being wrong. Using v1 we're going to get a bunch of false positive Proposer duties re-org (the dependent root will change but the shuffling won't).

Problem is, the v2 endpoint was only added recently, so using it would be a breaking change. Maybe we could try v2 and fallback to v1 if it's not available? I always hate writing that sort of logic though and it's prone to introduce timeout issues. Maybe using v2 by default and having a flag to disable it is cleaner and easier (and we can delete the flag eventually after Gloas).