Add explicit priority ordering across HTTPRoutes

[kxu-stripe]

What would you like to be added:

An opt-in way to explicitly control match order across HTTPRoutes attached to the same listener. Existing specificity-based ordering should remain unchanged when unused.

Why this is needed:
Priority-based load balancers such as AWS ALB use first-match-wins. During migration from such routing stacks, a less-specific route may intentionally need to match first in order to preserve parity.

Gateway API instead orders matches by specificity, followed by creation timestamp and resource name. Users cannot directly control this order without changing match conditions in a convoluted way.

This makes it difficult to migrate existing routing configurations or manage overlapping rules split across multiple HTTPRoutes.

Context:

• Explicit route priority across HTTPRoutes envoyproxy/gateway#9592
• PoC: feat: add opt-in explicit route priority under preserveRouteOrder envoyproxy/gateway#9591

[zhaohuabing]

+1. This is a real blocker for migration.

Specificity ordering is a fine default, but users migrating from first-match-wins stacks have no way to express the order they need, short of contorting match conditions. And once rules are split across HTTPRoutes, the only tie-breakers left are creationTimestamp and name, which aren't things a user can declare.

An opt-in priority that leaves the current ordering untouched when unset seems like the right shape.

[youngnick]

I'd like to see some examples of things that can't be done with specificity ordering.

The thing is, once we add an optional ordering thing, it's here forever, and will be a cost we pay with every new feature added. What happens with ListenerSet when we have explicit priority? There is a mutliplicative to exponential complexity cost for each optional thing we add in a fundamental thing like matching, especially cross-resource matching. That's the long-term effect.

Specificity ordering is already pretty complicated, and layering optional explicit ordering on the top is going to impose a large conformance test and implementation tax, even in the short term.

So yes, I would like some evidence that this is a "this is impossible to represent using specifictiy matching", not just "this is difficult to represent using specificity matching". I am strongly not in favor of having to deal with the consequences of adding this forever if the tradeoff does not also add significant value.