Add getHeader SSZ support

[jtraglia]

📝 Summary

This PR adds SSZ support for getHeader endpoint. Please see:

• https://github.com/ethereum/builder-specs/blob/main/apis/builder/header.yaml

✅ I have run these commands

• make lint
• make test-race
• go mod tidy

[0xTylerHolmes]

I think they are fine, but two things that caught my attention:

1. Reusing a request object (it is fine if body == nil)
2. Double close scenarios (io.Closer specifies that calls to Close after first call is considered undefined; though I think it is fine here)

First thought that addresses both of these and simplifies things a bit is if we define a doRequest function inside get_header that we can use to handle both the SSZ and JSON request attempts:

doRequest := func(accept string) (*http.Response, error) {
                req, err := http.NewRequestWithContext(context.Background(), http.MethodGet, url, nil)
                if err != nil {
                    return nil, err
                }
                // <insert request prep>
                req.Header.Set("Accept", accept)
                return m.httpClientGetHeader.Do(req)
            }

Then we can do something like:

            // ssz attempt
            resp, err := doRequest("application/octet-stream")
            if err != nil {
                …
                return
            }
            // json if relay does not support ssz
            if resp.StatusCode == http.StatusNotAcceptable {
                resp.Body.Close()
                logRelay.Debug("SSZ not accepted, trying JSON")
                resp, err = doRequest("application/json")
                if err != nil {
                    …
		    return
                }
            }
            defer resp.Body.Close()
            // continue rest of execution
            ...

edit: get_header should probably use a context that we pass to the NewRequestWithContext so we can handle timeouts.

[nflaig]

While this approach works I am not sure about the feasibility in practice due to time constraints, I think it would be best to use q-weighted Accept headers as noted here. To handle the response body, you can look at the Content-Type header sent by server.

[jtraglia]

Oh interesting. So this can/should be done in a single request. I'll just forward whatever the client sends & handle the response with Content-Type like you suggest.

[jtraglia]

@nflaig if you have time to review this again, I would really appreciate it 🙏

[nflaig]

do all relays properly set this header, otherwise might be best to assume JSON if header is missing

[jtraglia]

Not sure. Defaulting to JSON sounds like a good idea to me. Will make this change.

[nflaig]

my only worry here would be that relays don't properly handle q-weighted Accept headers, which is fine as long as they default to JSON in that case, if they throw an error it would be problematic though

[nflaig]

if you need some test cases

[jtraglia]

I've incorporated these into this PR. But with two changes. If there is no accept header or the accept header isn't in the supported media types, we will default to JSON.

[nflaig]

If there is no accept header or the accept header isn't in the supported media types, we will default to JSON.

we do the same although would return 406 if client only accepts media types we don't support, it's handled here

[jtraglia]

Hmm yes. I like that idea. Will do the same.