[configrpc] Remove SanitizedEndpoint?

[mx-psi]

As far as I can tell, this function is not used by any code, either in core or contrib. Should we remove it?

[TylerHelmuth]

I think we need to reconsider removing this feature. #9616 showed the otlpexporter relies on it.

We could reproduce the functionality directly in the otlpexporter, but leaving it in configgrpc seems ok as well.

[mx-psi]

I think we need to reconsider removing this feature. #9616 showed the otlpexporter relies on it.

We could reproduce the functionality directly in the otlpexporter, but leaving it in configgrpc seems ok as well.

@TylerHelmuth Do we have more than one usage of this function? If not, I would vote to move this to the OTLP exporter

[TylerHelmuth]

@mx-psi it has been used in configgrpc's ToClientConn function for a long time. Looking at usage of ToClientConn, it is used in the otlpexporter, coralogixexporter, opencensusexporter, otelarrowexporter, skywalkingexporter, jaegerremotesamplingextension, and testbed.

[atoulme]

The OTLP exporter has another way to deal with sanitized endpoint by stripping the scheme of the URL at unmarshaling time.

OK, so for this to happen:

1. We need embedded struct unmarshaling support [confmap] confmap honors Unmarshal methods on config embedded structs. #9635
2. Then we can implement an unmarshaler for configgrpc. We need one anyway for [configgrpc] Clean up the logic associated with https endpoints #9537

[TylerHelmuth]

For the usage within ToClientConn we can make the otlpexporter implement its own version of SanatizeEndpoints since it is the only direct external use and then in configgrpc we can unexport SanitizedEndpoint to leave ToClientConn features intact. This reduces the size of configgrpc's public API with no end-user impact.

[mx-psi]

@TylerHelmuth As you said, I don't think uses on configrpc itself count; we can just unexport the function, my concern is about having it as part of the public API.