5579 extended http methods

[ashishb-solo]

Description

Enable extended HTTP methods. Prior to this change, Envoy only allowed a
limited set of HTTP methods, and anything not allowed in a hard-coded list
would be rejected. This change allows users to configure Envoy so that extended
methods, such as LABEL or UPDATE can be passed.

The code changes are fairly straightforward, but potential compatibility issues with future envoy releases are not straightforward, so I would appreciate if reviewers could focus in particular on this area.

API changes

• Created a new header validation settings message and exposed it at the HTTP Listener options level.

Code changes

• Create the HeaderValidation plugin to manage settings related to header validation

CI changes

• Added e2e tests (unit tests still needed)

Docs changes

• See documentation in .proto files

Context

https://soloio.slab.com/posts/extended-http-methods-design-doc-40j7pjeu

Interesting decisions

See slab document regarding status of option settings in upstream Envoy.

Testing steps

TODO

Notes for reviewers

Please read the design document linked on slab carefully to understand the current state of this feature in upstream Envoy, especially how it pertains to Universal Header Validation and the deprecation status of the features that we're using in upstream Envoy.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

BOT NOTES:
resolves #5579

[bewebi]

Overall seems like a good approach to me

We may also want to call out the potential breaking changes where we specify the Envoy version (ie here) so that there are no surprises, but I think there is/will be enough tests that will fail if/when allow_custom_methods is deprecated in Envoy that we aren't at risk of shipping something broken

The real risk is that there will be hidden required work at some point when we bump Envoy versions, but we're calling it out as loudly as possible while also describing the path forward, so I think the pain/surprise will be minimized

[ashishb-solo]

After a bit of discussion yesterday, we made the following decisions:

1. only enable this on the gateway (and possibly in settings) for now. we cannot decide exactly how we want lower level configurations (like route table) to override higher level configurations (ie. which one takes precedence), so let's hold off on making a decision here until we have to.

2. we can just pop all this functionality into the existing gloo plugin for hcm. no need to create a new one.

[solo-changelog-bot]

Issues linked to changelog:
#5579

[github-actions]

Visit the preview URL for this PR (updated for commit 257e0ac):

https://gloo-edge--pr9633-5579-extended-http-m-awemr4gz.web.app

_{(expires Tue, 02 Jul 2024 18:31:00 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 77c2b86e287749579b7ff9cadb81e099042ef677}

[ashishb-solo]

In the current iteration of the API, this is the configuration that would be used to allow custom http methods:

apiVersion: gateway.solo.io/v1
kind: Gateway
metadata:
  name: gateway-proxy
  namespace: gloo-system
spec:
  bindAddress: '::'
  bindPort: 8080
  httpGateway:
    options:
      headerValidationSettings:
        allowCustomMethods: {}

[sheidkamp]

A couple notes on the tests.

Would like to see a demo and/or testing steps before approval.