Allow injecting bootstrap info into xDS Filter API for config parsing

[sauravzg]

This sits on top of #12492 , so please view the commits after it.

Extend the xDS Filter API to support injecting bootstrap information into
filters during configuration parsing. This allows filters to access context
information (e.g., allowed gRPC services) from the resource loading layer
during configuration validation and parsing.

• Update Filter.Provider.parseFilterConfig and parseFilterConfigOverride
  to accept a FilterContext parameter.
• Introduce BootstrapInfoGrpcServiceContextProvider to encapsulate
  bootstrap info for context resolution.
• Update XdsListenerResource and XdsRouteConfigureResource to
  construct and pass FilterContext during configuration parsing.
• Update sub-filters (FaultFilter, RbacFilter, GcpAuthenticationFilter,
  RouterFilter) to match the updated FilterContext signature.

Known Gaps & Limitations:

1. MetricHolder: Propagation of MetricHolder is not supported with
   this approach currently and is planned for support in a later phase.
2. NameResolverRegistry: Propagation is deferred for consistency. While
   it could be passed from XdsNameResolver on the client side, there is
   no equivalent mechanism on the server side. To ensure consistent behavior,
   DefaultRegistry is used when validating schemes and creating channels.

[sauravzg]

@kannanjgithub @AgraVator PTAL and add yourself as reviewers on the PR. Thanks.

[kannanjgithub]

The interface naming suggests that the trust management for the GrpcService can come from > 1 places, of which we have implemented the bootstrap based one. But A102 says no such thing and has only made the trust control come from the bootstrap config. So both the interface and the implementation should have "Bootstrap" in the name.

As far the need for creating an interface itself, I don't see the need for it. The provider's behavior is solely from BootstrapInfo and ServerInfo which are in-turn just holders of attributes which can just be done from the test with appropriate values it needs for these arguments, instead of using a mock for the provider.

[ejona86]

We discussed getting rid of GrpcServiceXdsContextProvider and just exposing ServerInfo/BootstrapInfo in the FilterContext. That's fine; we don't need to change that discussion.

But I think I would have accepted this hiding approach more if it was merged with GrpcServiceConfigParser. My problem with it right now is the API split of what-does-what is really awkward. For example, if this method was parseGoogleGrpcConfig(GrpcService.GoogleGrpc googleGrpcProto), then it would work better. Basically, one extreme or the other works, but GrpcServiceXdsContext is awkward because it is silently coupled to GrpcServiceConfigParser, with both classes needing intimate knowledge of the other. There could definitely be other API splits that might work, but this lacked cohesion. If the three fields of BootstrapInfoGrpcServiceContextProvider had been directly exposed on FilterContext, that has practically the same amount of data hiding and yet less coupling because GrpcServiceXdsContext is currently single-purpose; it assumes how the fields are used.