Return not synced errors for endpoints that require syncing

[eserilev]

Issue Addressed

#5131

Proposed Changes

For some beacon api endpoints we are returning 500's while syncing when we should be returning 503's. Our not_while_syncing_filter should be taking care of this edge case, but apparently something with Warp is causing us to still return 500s. I think its due to the way warp decides to backtrack and prioritize errors. Reading here it seems warp collects error messages and shows only the highest priority error. So maybe an Internal Server Error somehow gets raised downstream from the not_while_syncing filter and overrides Service Unavailable?

Based on a suggestion @michaelsproul made in discord I forced the failure check into the relevant .then blocks.

Testing locally I was able to get the appropriate 503 response + error message

curl -X POST -H "Content-Type: application/json" --data '["1552654"]' "http://localhost:5052/eth/v1/validator/duties/sync/123"

{"code":503,"message":"SERVICE_UNAVAILABLE: beacon node is syncing: sync is stalled","stacktraces":[]}%   

[dapplion]

Cheeky warp and_then semantics.. Change is correct 👍 and not_synced_filter?; looks fine to me

[michaelsproul]

let's goo

[michaelsproul]

@Mergifyio queue

[mergify]

queue

🛑 The pull request has been removed from the queue default

The queue conditions cannot be satisfied due to failing checks.

You can take a look at Queue: Embarked in merge queue check runs for more details.

In case of a failure due to a flaky test, you should first retrigger the CI.
Then, re-embark the pull request into the merge queue by posting the comment
@mergifyio refresh on the pull request.

[michaelsproul]

@Mergifyio requeue

[mergify]

requeue

✅ This pull request will be re-embarked automatically

The followup queue command will be automatically executed to re-embark the pull request

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at f4cdcea