feat: support qvalue weighting in Accept headers

[jshufro]

Motivation

Improves compatibility with attestantio's beacon client, and other libraries in general.

Description

Adds a utility function to parse and prioritize Media Types based on the Accept header and RFC-9110.
Preserves the default behavior of returning json instead of a 406 (since the beacon-API doesn't seem to like HTTP 406).

Adds unit tests for the new function.

Closes #5966

Steps to test or reproduce

Tested with yarn test:unit --scope @lodestar/api

[CLAassistant]

All committers have signed the CLA.

[jshufro]

@nflaig lint / type errors from the previous CI runs should now be resolved

[matthewkeil]

Really nice job! Your rocked thoroughly on this PR. Please check out the comments and let me know your thoughts. It is also possible that some of the other team members will leave a few comments for you as well!

[nflaig]

Looks pretty good overall

[nflaig]

Looks good to me, thanks @jshufro. This will become increasingly important once more APIs support ssz and json format (#5128).

This is also a requirement outlined in ethereum/beacon-APIs#250

existing beacon API servers must at a minimum support the Accept header with multiple entries and quality values (e.g. Accept: application/octet-stream;q=1.0,application/json;q=0.9). Note that this appears to be the case for current beacon API server implementations, in that they at least will currently return JSON data when presented with this header

I also think defaulting to json is good for now, as far as I know fastify at least returns a 415 if no content-type header is provided. The spec issue suggests 415 error code but looking at the current spec it seems to have both 406 and 415

servers add support for the '415' error code when none of the options in the Accept header can be provided

Can revisit error behavior / codes another time.

[jshufro]

This will become increasingly important once more APIs support ssz and json format

Can't come soon enough! Json is great for debugging but very, very slow :(

More immediately this will stop rescue-proxy from crashing lodestar here: https://github.com/Rocket-Rescue-Node/rescue-proxy/blob/master/consensuslayer/consensus-layer.go#L184

This function creates an index based on 0x01 credentials and is required for us to support non-rocketpool validators, a feature we're excited to roll out. Thanks for the quick reviews!

[nflaig]

More immediately this will stop rescue-proxy from crashing lodestar here: https://github.com/Rocket-Rescue-Node/rescue-proxy/blob/master/consensuslayer/consensus-layer.go#L184

Right, the response when getting validators without specifying pubkeys / indexes is even bigger than the state response on mainnet. We should look into supporting ssz for this API, it is also quite frequently used by the validator client.

[wemeetagain]

Good job on this.
I'd love to hear more about your usecases wrt ssz responses. Feel free to comment on that issue in favor.

[matthewkeil]

This looks really nice! Thank you for the contribution!

[wemeetagain]

🎉 This PR is included in v1.12.0 🎉