dynamic_modules: adds a matcher based on Dynamic Modules

[agrawroh]

Description

This PR adds a dynamic module input matcher extension and HTTP data input which allows implementing custom matching logic in external languages (Rust, Go, C) via dynamic modules. This enables a lot of use-cases where we need to write some advanced logic for route matching.

---

Commit Message: dynamic_modules: adds a matcher based on Dynamic Modules
Additional Description: Added a dynamic module input matcher extension and HTTP data input which allows implementing custom matching logic in external languages via dynamic modules.
Risk Level: Low
Testing: Added Tests
Docs Changes: Added
Release Notes: Added

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @wbpcode
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #43408 was opened by agrawroh.

see: more, trace.

[wbpcode]

Thanks for your contribution. Could you share your original requirement here and see is there easier way to go? (although I didn't against this, but also think we may needn't add dynamic module at everywhere if we have some simpler solution.)

/wait-any

[agrawroh]

Thanks for your contribution. Could you share your original requirement here and see is there easier way to go? (although I didn't against this, but also think we may needn't add dynamic module at everywhere if we have some simpler solution.)

/wait-any

@wbpcode Thanks for taking a look!

Today we run a sidecar (via ExtAuthZ) that inspects the incoming OAuth token, extracts claims from the JWT payload, and combines them with other request headers to make routing decisions. After this, the sidecar forces a route re-match in Envoy. The goal for us is to eliminate the sidecar entirely and move this logic into Envoy itself via a Dynamic Module matcher. This would gives us the ability to implement arbitrarily complex matching logic without the latency and operational overhead of a separate process.

I could imagine many other additional use-cases which we're looking to consolidate:

1. Access Log Filtering: We have custom logic that decides whether to emit access log entries based on a combination of request + response attributes. Today, this is scattered across sidecar logic and Envoy configuration and having a dynamic module matcher would let us express it cleanly in RUST with full access to headers and response metadata would be extremely useful.
2. Filter Chain Matcher: We have a lot of filter chains today and there are opportunities to collapse some of these filter chains if we get an advanced matcher that could encapsulate some of the logic which we can't easily do as part of the regular xDS matcher we have available today.

[wbpcode]

LGTM. Thanks.