reconcile matching throughout Envoy config/API

[mattklein123]

We have a lot of different matching going on (route, RBAC, Tap, filter chain, etc.) and we probably could share more matching infrastructure across components. This issue tracks figuring out a plan to see what can be shared.

[mergeconflict]

I have a proposal (now with more detail and fewer owl drawings). I'm hoping to use it as the basis for #6453.

Attn: @mattklein123 @junr03 @htuch.

[htuch]

LGTM, I left a few minor comments.

[mattklein123]

In general this LGTM, but I left one comment about when the matchers run. I think this might be problematic in some cases and will need more thinking.

I wonder if it's worth it to have the reference system to begin with vs. just having centralized matching protos and implementation and allowing them to run in different places...

[htuch]

Within the scope of v4 / UDPA is a more general treatment of matching, see for example the match-action approach in cncf/udpa#4 and https://docs.google.com/document/d/1orxTIL9FXtgmyl5TtPRBqGjgp1ekL7oOKDd95wxeCRY/edit.

@mergeconflict do you have any thoughts on where we might take this at an API level in the scope of v3 (targeted end-of-quarter)? Are there some low hanging fruit we can address now and/or aspects of this that belong in v4 (UDPA)?

[htuch]

@mattklein123 I'm wondering if we can add the new unified matcher to v2 and then deprecate existing matchers, allowing for their removal in v3. This would be the preferable approach IMHO, rather than a radical change in how matching is done alongside the rest of the v3 work. If that makes sense, do you know who might own this specific task?

[mattklein123]

The plan above sounds good, but TBH this is a giant work item and I'm doubtful we are going to find someone to do it. We will probably end up punting to v4 but lets leave help wanted in case someone is interested?

[htuch]

Ack. I've cleared this from the 1.12.0 milestone.

[htuch]

Related somewhat to #9656