Cert validator is extendable in upstream Envoy. As platforms such as Android and iOS provide their own cert validation APIs, E-M should use these platform provided APIs instead of, as the default cert validator does in upstream Envoy, calling into boring SSL on its own.
The plan for Android is documented in #1575. As we are designing the Android implementation with External::Api, which can be used for iOS extension in the future, we need to decide how to config the non-Android platform to still use the upstream Envoy's default cert validator in the transition period.

The Android config would look like:

transport_socket:
    name: envoy.transport_sockets.tls
    typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
      common_tls_context:
        # omit trusted_ca and ca_certificate_provider_instance
        ...
        custom_validator_config:
           name: "envoy_mobile.cert_validator.platform_bridge_cert_validator"
           typed_config:
             "@type": type.googleapis.com/envoymobile.extensions.transport_socket.cert_validator.v3.PlatformBridgeCertValidator
             platform_name: ${platform_specific_key}

with an Android specific ${platform_specific_key}.

For other platforms, before they switch to use the platform provided cert validator, they should be able to use the current transport socket config with trusted_ca or ca_certificate_provider_instance and without custom_validator_config. So their config looks like
a)

transport_socket:
    name: envoy.transport_sockets.tls
    typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
      common_tls_context:
        trusted_ca: ${ca_config}
        ...

To do so, the config pipeline need to generate transport socket config differently for Android and non-Andoid platforms.

b) The other option is to use the same custom_validator_config with a different ${platform_specific_key}, so their config pipeline will be the same. But as they haven't switched to using the platform provided APIs, their platform code should call into Envoy default cert validator.

We can gather thoughts here about which direction to take. IMO if a) is feasible, we should avoid b) as it causes extra layer of indirection from native code to platform and then back to native and the indirection will only be used in transition period.