Prometheus compatibility: do not duplicate equal values when colliding attribute keys are concatenated

[jmichalek132]

What are you trying to achieve?

The Metric Attributes section of the Prometheus and OpenMetrics compatibility spec (Stable) says:

This conversion, or other labels (e.g. otel_scope_name) added by this specification, may cause
different OpenTelemetry keys to map to the same Prometheus key. In such cases, the values MUST be
concatenated together, separated by ;, and ordered by the lexicographical order of the original keys.

When the colliding attributes carry the same value, the literal reading mandates duplicating it.
For example, a resource with both k8s.pod.name="payments-7d9f8" (set by the k8s attributes
processor) and k8s_pod_name="payments-7d9f8" (set by an SDK or relabeling) produces:

k8s_pod_name="payments-7d9f8;payments-7d9f8"

The duplicated value carries no information, looks like data corruption to users, breaks joins
on target_info labels, and changes series identity for no benefit. I propose the spec requires
deduplicating equal values: concatenate the distinct values only, still ;-separated and ordered
by the lexicographical order of the original keys, and when all colliding values are equal, use the
single value as-is.

Current state across implementations

The ecosystem is already inconsistent, which is the main reason to clarify the spec either way:

• The Collector's prometheusremotewrite translator stopped appending equal values in
  [exporter/prometheusremotewrite] only append colliding attributes values if they are different opentelemetry-collector-contrib#36928 (merged January 2025), deviating from the
  strict MUST: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/translator/prometheusremotewrite/helper.go#L153-L156
  (Note its check compares against the accumulated string, so a,b,b still produces a;b;b;
  a spec clarification should define distinct-value semantics rather than this approximation.)
• The Prometheus OTLP receiver concatenates unconditionally:
  https://github.com/prometheus/prometheus/blob/main/storage/remote/otlptranslator/prometheusremotewrite/helper.go#L121-L122
• Grafana Mimir and Cortex both reuse the Prometheus translator and inherit the same behavior.

Proposed wording

In such cases, the distinct values MUST be concatenated together, separated by ;, and ordered by
the lexicographical order of the original keys. Values equal to an already included value MUST NOT
be repeated. In particular, when all colliding values are equal, the result is the single value.

Compatibility

This only changes output where today's output contains repeated values (val;val), which no
consumer is known to rely on; queries matching the duplicated form would need updating, which is
the same class of breakage the Collector already shipped in January 2025 without reported issues.

I am happy to send a PR for the spec change if maintainers agree with the direction.