[Prometheus] Exporter should support 'NoTranslation' mode

[ywwg]

Problem Statement

Currently the only way to control escaping in the prometheusexporter is to set common/model.NameValidationScheme. This value is deprecated and shouldn't be used this way.

Proposed Solution

We should unify the configuration options with the consensus solutions being implemented in Prometheus and Otel-Collector: Supporting an explicit "NoTranslation" mode that exposes unescaped metrics on the Prometheus endpoint.

The consensus solution involves two booleans and three possible settings:

1. "no-translation" mode -- native Otel metric and label names
2. Prometheus-translation mode with suffixes
3. Prometheus-translation mode without suffixes

The current consensus is not to support NoTranslation + EnableSuffixes. If there is demand for this mode, for instance to prevent metric name collisions, we can add it.

Alternatives

Other methods could be used to control the chosen escaping scheme, like a library global variable, but that's a poor way to control behavior.

Prior Art

OtelCollectorConbtrib's prometheusexporter and prometheusremotewriteexporter are both moving towards config values. Prometheus' otel endpoint similarly will have config-controlled settings.

[ywwg]

Also, can a codeowner please assign me to this bug

[dmathieu]

Related: #6590

You have more context than me here, but I wonder if we need that configuration at all.
In a not-too-far future, this config will only have one possible value, yet we will have to support it until we have a major release.

I know relying on deprecated configs isn't great. When we discussed about that at Kubecon, @bwplotka was considering removing the deprecation notice.

[ywwg]

In a not-too-far future, this config will only have one possible value

I think I drafted this issue badly, conflating the Escaping Scheme configuration with the availability of configuration to determine how metrics can be translated for scraping by prometheus.

See: open-telemetry/opentelemetry-collector-contrib#35459

Currently the predicted end state is three options in the SDK:

1. "no-translation" mode -- native Otel metric and label names
2. Prometheus-translation mode with suffixes
3. Prometheus-translation mode without suffixes

We currently have AddMetricSuffixes already, we just need to add TranslationStrategy similar to prometheus/prometheus#16441. We understand this will require updating the spec per open-telemetry/opentelemetry-collector-contrib#39706.

This is also related to: #6704

I will update the wording of this bug to better reflect the intent.

[dashpole]

Currently the only way to control escaping in the prometheusexporter is to set common/model.NameValidationScheme.

I thought it was controlled using content negotiation?

[ywwg]

It is meant to be controlled in content negotiation but the relevant code does not exist in the exporter yet, so that definitely needs to be implemented. But we have also found use for an override as described by this bug -- even if prometheus says "allow-utf-8" it is useful for clients to be able to be configured to still send escaped metrics. Prometheus-translated metrics are of course 100% valid UTF-8, so this is not a violation of any spec. This allows users to enable UTF-8 in prometheus but still control how their metrics appear, which helps manage upgrades and rollouts.