SSZ Support for `submitBlindedBlock ` and `getHeader` endpoints

[ryanschneider]

With ethereum/builder-specs#104 accepted to the spec, we should update with the required changes.

Note that I'm not overly familiar with the relay codebase, so take all of the below with a grain of salt, but this is my proposed set of changes:

Overall Goal

So to reiterate the above builder-spec PR, the goal is to support SSZ for these endpoints in a backwards compatible way:

• before SSZ support lands, the relay should return appropriate 4xx error codes
• getHeader should allow SSZ encoding of the response.
• submitBlindedBlock should allow both SSZ requests and responses.

Milestone 0: Housekeeping (GetPayload vs SubmitBlindedBlock)

When researching the required changes, one thing that threw me off is that the builder-spec refers to the /eth/v1/builder/blinded_blocks endpoint as the submitBlindedBlock operation here: https://github.com/ethereum/builder-specs/blob/main/apis/builder/blinded_blocks.yaml#L2

However the mev-boost-relay codebase uses the term getPayload for that operation. IMO we should consider updating the code to use submitBlindedBlock instead. However, the term "Get Payload" is used in DB schemas and metrics, so this might not be practical.

Milestone 1: Explicitly reject SSZ

Accept header parsing

So, the first step is IMO to parse the suggested Accept header, and explicitly reject any that resolve to anything other than application/json.

The logic should largely involve:

• Update handleGetHeader and handleGetPayload (or handleSubmitBlindedBlock if milestone 0 occurs) to parse the Accept header.
• Be sure to handle the weighted case as outlined at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept
• If the Accept header does not contain application/json (at any weight) then return status 406 as outlined here: https://github.com/ethereum/builder-specs/blob/main/types/http.yaml#L24

Content-Type parsing

Next, the handleGetPayload/handleSubmitBlindedBlock handler should correctly reject SSZ (or any non-JSON Content-Type):

• If Content-Type is omitted, assume JSON.
• If Content-Type is included but contains any value other than application/json the endpoint should return a 415 as outlined here: https://github.com/ethereum/builder-specs/blob/main/types/http.yaml#L47

The above is the minimal change required to be "in spec" with the SSZ updates, but of course we should continue on to actually supporting SSZ.

Milestone 2: SSZ Support

With Milestone 1 in place, we can go forward with actually supporting SSZ, which would entail:

In handleGetPayload:

• Allowing application/octet-stream in the Content-Type header.
• Requiring the Eth-Consensus-Version header if Content-Type: application/octet-stream is included.
• Decode the payload as either SSZ or JSON based on the Content-Type header.

And in both handleGetHeader and handleGetPayload:

• Allow application/octet-stream in the Accept header.
• Add a new RespondWithContentType or similarly named method that can respond w/ both JSON and SSZ, use this instead of RespondOK (RespondError and continue to only send JSON).

Also note that Milestone 2 must be deployed atomically since allowing Accept: octet-stream in the handleGetPayload handlers is how relays signal that they support SSZ for both endpoints.