Add details and example of sublinear route matching using Generic Matching API

[krajshiva]

Commit Message:
Additional Description: Add details on sublinear route matching with examples using Generic Matching API
Risk Level: Low
Testing:
Docs Changes: Add more details for routing using Generic Matching API
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

[krajshiva]

@phlax closed #37117 and updated content in user doc space as suggested.

[phlax]

currently this is failing a lot of CI - most importantly the docs build

if you can fix that i can do a more thorough review

ping me offline if you want help figuring out what needs to be changed

re the configs - one of the reasons we use a complete bootstrap config and literalinclude is that the configs are then validated (in a couple of ways)

[phlax]

these clusters will need to be specified - the config is not valid otherwise

[phlax]

Suggested change

An incoming request to Envoy needs to be matched to a cluster based on defined `routes <https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-virtualhost>`_. Typically, a well understood, linear route search matching with O(n) search cost (see `Virtual Host <https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-virtualhost>`_ → `Routes <https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-route>`_) is employed which can become a scalability issue with higher latencies as the number of routes go up to o(1k+). To overcome these scalability challenges the Generic Matcher API ( `Virtual Host → matcher{} <https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-virtualhost>`_) → `matcher_tree <https://www.envoyproxy.io/docs/envoy/latest/xds/type/matcher/v3/matcher.proto#envoy-v3-api-msg-xds-type-matcher-v3-matcher-matchertree>`_ can offer a robust and flexible framework for route matching with two distinct sublinear matching implementations:

An incoming request to Envoy needs to be matched to a cluster based on defined :ref:`routes <envoy_v3_api_msg_config.route.v3.VirtualHost>`_. Typically, a well understood, linear route search matching with O(n) search cost (see :ref:`Virtual Host <envoy_v3_api_msg_config.route.v3.VirtualHost>`_ → :ref:`Routes <envoy_v3_api_msg_config.route.v3.Route>`_) is employed which can become a scalability issue with higher latencies as the number of routes go up to o(1k+). To overcome these scalability challenges the Generic Matcher API ( `Virtual Host → matcher{} <https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-virtualhost>`_) → `matcher_tree <https://www.envoyproxy.io/docs/envoy/latest/xds/type/matcher/v3/matcher.proto#envoy-v3-api-msg-xds-type-matcher-v3-matcher-matchertree>`_ can offer a robust and flexible framework for route matching with two distinct sublinear matching implementations:

internal links need to use :ref: - ive updated a couple, but im not 100% that ive pointed the links to the correct place

you can find the ref target by clicking "View page source" on the rendered docs pages

not sure exactly the issue that is preventing the docs from building - but its related to these links