Revisit duplicate route decorators if config v1 persists

[MrAlias]

Component

OBI (eBPF instrumentation)

Status

This is a deferred, conditional tracking issue. It is not work we intend to prioritize now and it is not a blocker for #2680.

Revisit it only if config v1 remains supported for substantially longer than currently planned, or if maintaining both route decorators causes a concrete problem.

Context

PR #2680 introduces directional HTTP route policies for config v2 while retaining the non-directional provideRoutes path solely for config v1 compatibility. This leaves some duplicated route decoration logic.

Adding a compatibility layer now to translate v1 route configuration into the directional representation would require v1 behavioral-parity work, particularly around service-level routing precedence. If config v1 is retired on the expected timeline, that transitional work would have little value because the non-directional path can simply be deleted as part of the v1 sunset.

When to revisit

Reassess this issue only if either condition becomes true:

• Config v1 support is extended for a prolonged period.
• The duplicate route decoration paths cause a concrete bug or material maintenance burden.

Otherwise, leave the implementations as they are and remove provideRoutes with the rest of config v1.

Possible direction if revisited

If the additional compatibility work becomes justified, translate non-directional v1 route settings into both incoming and outgoing directional policies, use provideDirectionalRoutes for both config versions, and remove the separate provideRoutes runtime path.

This direction would need explicit behavioral-parity coverage for v1, including service-level route precedence. It should not change the config v2 directional semantics or the per-service, field-by-field override behavior established by #2680.

Additional context

Follow-up to #2680:

• Original simplification suggestion
• Decision to defer until the config v1 sunset