EPF Cohort 3 Dev Update 3 (pavignol)

I have been falling behind a bit on my updates as I was deep into coding, so this update will be for the entire moth of November. I'll try to write updates every week or every 2 weeks for the remaining weeks of the cohort.

Added customizable endpoints for the Validator's REST API

The first feature I worked on during this period was to add customizable endpoints for the validator's REST API in Prysm. What this change does is refactoring the entire validator codebase to be able to use the beacon REST API instead of the gRPC one when the validator communicates with the beacon node. This allows us to start testing our REST API endpoints as we add them, even though we're just getting started. When building Prysm with the --config=beacon_api flag, the beacon REST API implementation is used; otherwise, the old gRPC implementation is used instead.

Added a beacon REST API implementation for Validator's WaitForChainStart

WaitForChainStart is an endpoint specific to Prysm, but basically all it needs to do is call the /eth/v1/beacon/genesis endpoint described in the Beacon Node API spec. A particularity of WaitForChainStart is that, unlike /eth/v1/beacon/genesis, it should block when it receives an error 404 and only return once it finally receives a successful 200 code or another error code. Alas, to keep the PR concise, I postponed the blocking functionality and implemented it in another PR, a few days later.

Added a gRPC fallback mode to the Validator beacon REST API

Previously, when Prysm was built with the --config=beacon_api and a validator function that didn't have a beacon REST API implementation was called, it simply panicked and exited early. Although it made it clear which functions were implemented and which ones were not, it made it really hard to thoroughly test more complex endpoints since the validator would crash before reaching time. To work around this, I added a gRPC fallback mode to the Validator beacon REST API. REST API implementations will be used when they are available, but if they haven't been implemented yet, it will successfully fallback to the gRPC version.

Onboarded the validator's beacon REST API tests to CI

As we started added more endpoints and unit tests, we realized that the tests were not running during CI because the bazel file was lacking the gotags = ["use_beacon_api"] attribute, so I went ahead and onboarded them

Made the validator REST API's WaitForChainStart blocking

As explained above, the second part of the WaitForChainStart function is to stay blocked as long as it's getting 404 errors, and only return once a non-404 error or a 200 status is received. To implement this functionaly, I simply keep pinging the beacon node with delays of 1 second until it stops returning a 404 error.