[prometheusreceiver/prometheusexporter] Handle units in prometheus metric names

[dashpole]

After open-telemetry/opentelemetry-specification#2440, prometheus exporters must add units to as a suffix to the metric name (before type suffixes), and the prometheus receiver must trim a unit suffix after trimming type suffixes. I.e.:

# TYPE request_duration_seconds counter
request_duration_seconds_total{}

is broken down into OTLP

{
  name: request_duration,
  unit: seconds, 
  type: counter,
  is_monotonic: true,
}

[bertysentry]

Is this ever going to be implemented? I think it's a very important feature to make sure metric naming conventions are followed on both OpenTelemetry and Prometheus.

But when this will be implemented, it will be a breaking change on the receiving end! (think of a Grafana dashboard relying on Otel metrics named after the Otel metrics convention, that would suddenly break once this is merged into the collector).

So, this is the kind of change that needs to be implemented as soon as possible, to break as few things as possible.

[dashpole]

Yes, this will definitely be implemented eventually, and I agree with the urgency. It is just a matter of people having time to do the work. You can see the full set of prom-spec items here: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues?q=is%3Aopen+label%3Acomp%3Aprometheus+label%3Aspec%3Ametrics+

[bertysentry]

At some point, my company will need this feature in prometheusexporter so we'll probably give it a try. However, I'm concerned with the many edge cases where appending Otel metrics will have adverse effects (when the metric name already contains the unit, or when the unit is a long string, etc.)

[bertysentry]

@dashpole If you have time to have a look at the #10028 PR (just describing the change, before going down to the implementation)