[xds] Relax the CHECK on factories for typed per-filter config

[stevenzzzz]

Title: Do not reject the typed per-filter-config if a factory can't be found, remove binaries version coupling.

Description:
Right now for the typedConfig in route we demand the factory class to be linked in at Envoy, otherwise it rejects the whole DiscoveryResponse.
This adds coupling between management server and Envoy, which introduces complexity to rollout/backs of these binaries.

Let's be more tolerant to such config change. (with a runtime feature flag guard), similar to Protobuf upgrade.

Instead of throwing an exception, let's do logging and adding stats for such missing factories.

[stevenzzzz]

cc @htuch

[stevenzzzz]

the check we want to remove: https://github.com/envoyproxy/envoy/blob/main/source/common/router/config_impl.cc#L1532-L1533

[stevenzzzz]

cc @AndresGuedez

[mattklein123]

I think it would be reasonable for this to be configurable, much like we do for other validation options. cc @dmitri-d

[dmitri-d]

To clarify: is the idea to accept a "partial" route config update by ignoring per_filter_configs whose factories cannot be found?

[htuch]

CC @markdroth who introduced this. I agree it would be useful to make this configurable, probably fine to do it at bootstrap level.

[stevenzzzz]

some clarification: we want to break the management server and Envoy version coupling.
In some cases, it's fine to "ignore" some features for some routes, (esp for a multi-tenancy proxy).

I think we can add a switch for such factories: if mandatory, let's throw, if "optional", feel safe to ignore.

[markdroth]

I think this would be best addressed by fixing #15025. That way, the control plane can explicitly indicate which filters should be optional and which are required.

Note that gRPC has already implemented support for the new is_optional fields.

[markdroth]

Also, I don't think I introduced Envoy's current behavior -- I think it has always done this.

[soulxu]

I think this would be best addressed by fixing #15025. That way, the control plane can explicitly indicate which filters should be optional and which are required.

Note that gRPC has already implemented support for the new is_optional fields.

emm....I missed this comments, looks like I fixed it as a wrong way.

[soulxu]

I think this would be best addressed by fixing #15025. That way, the control plane can explicitly indicate which filters should be optional and which are required.
Note that gRPC has already implemented support for the new is_optional fields.

emm....I missed this comments, looks like I fixed it as a wrong way.

Close my PR. The optional filter is preferred fixed. @markdroth let me know if you need any volunteers to help on #15025.

[markdroth]

As far as I know, no one is working on that issue, so you should feel free to send a PR for that.

We may want to just close this bug as a dup of #15025.