router: scope upstream HTTP filter chain to the connection manager stat prefix

[fl0Lec]

Commit Message: router: scope upstream HTTP filter chain to the connection manager stat prefix
Additional Description:

Generative AI (Claude) was used to assist with this change; I have reviewed and understand all of the code.

The router builds its upstream_http_filters chain at the root stats scope: in FilterConfig's constructor the upstream FilterChainHelper is given context.scope() (the root scope) and a prefix derived from context.scope().prefix() (empty). As a result, stats emitted by upstream HTTP filters configured via Router.upstream_http_filters have no downstream context.

By contrast, the cluster-level upstream filter chain (HttpProtocolOptions.http_filters, built in upstream_impl.cc) is scoped to cluster.<name>..

This change builds the router's upstream filter chain under a stats scope that inherits the connection manager's stat prefix (http.<stat_prefix>.) — which the router already receives as the stat_prefix StatName — mirroring the cluster path. Filters that read their stats scope now emit stats under http.<stat_prefix>. instead of the root scope.

Open question for maintainers: this changes the stat path for existing upstream_http_filters users, so a runtime guard would normally be expected. However, the scope is chosen once at config-construction time (not on the request path), so a reloadable_features guard does not map cleanly. Happy to gate it differently if preferred.

Risk Level: Low (only affects the stats scope of upstream_http_filters, a rarely-used feature; no data-plane behavior change).
Testing: //test/common/router:router_upstream_filter_test passes; //source/common/router:router_lib builds.
Docs Changes: n/a
Release Notes: added (minor_behavior_changes).
Platform Specific Features: n/a

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #45666 was opened by fl0Lec.

see: more, trace.

[fl0Lec]

/retest

[botengyao]

thanks for working on it.

/wait

[botengyao]

This is a behavior change, could you please add a runtime guard on it?

[repokitteh-read-only]

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).

🐱

Caused by: #45666 was synchronize by fl0Lec.

see: more, trace.

[fl0Lec]

/retest

[fl0Lec]

@botengyao gentle bump on this one

[botengyao]

lgtm, thanks!

defer to @wbpcode for a second eye, I think this is simple to go with the runtime guard.

[wbpcode]

Thanks for working on this.

First, the current context.scope() is not root scope, it's filter chain scope with empty prefix.
Second, the current router's implementation actually correctly matches the downstream HTTP filters' implementation. The scope self has an empty prefix, and the parent's prefix is propagated to the filter factory by a string and the filter could optionally use it or not. (I actually agree that letting the parent create a prefixed scope is better design, then the sub filters needn't to care about the stat prefix. However, previous design works from the start of this project, even if we want to migrate, it should be done in a more smooth way).

It's more like the cluster's HTTP filter chain has an unexpected implementation.

Note, most of the HTTP filters will concatenate the parent prefix string http.example. to the own prefix and stat names and create the stats under the factory context's scope.

With these changes, it may result in unexpected stats names like: http.example.http.example.foo or cluster.example.cluster.example.foo when these filters are used as upstream filters.

That's say, we may need to update the cluster's implementation to match the router rather to update router.

cc @botengyao

[fl0Lec]

Closing this in favor of #45987, which takes the approach suggested in review: instead of creating a sub-scope in the router, the fix is applied at the stats_prefix string level — passing the correct prefix to FilterChainHelper from both router.cc and upstream_impl.cc, and removing the EMPTY_STRING workaround in the upstream RBAC filter config. Thanks for the feedback that pointed in the right direction.