Clarify how metric metadata and type suffixes are handled

[dashpole]

Fixes #2437

Changes

Explicitly call out how to handle prometheus metric metadata and OTLP metric metadata. Most of this was implicit, but this makes it more explicit. This PR also clarifies that _total suffixes are trimmed from metrics, which is already the case in the collector.

It proposes the following changes from the current state:

• trim _info suffixes from info metrics (after support for info is implemented: [prometheusreceiver] Convert Info and StateSet metrics to non-monotonic sums opentelemetry-collector-contrib#8516)
• Add unit suffixes to prometheus exporters.
• Trim unit suffixes in the prometheus receiver.

Unit suffixes are required by the OpenMetrics spec

cc @aabmass @legendecas @jmacd @Aneurysm9

[reyang]

LGTM, there might be some corner cases such as https://github.com/open-telemetry/opentelemetry-specification/pull/2440/files#r834957165 but I guess it's probably a rare case.

[Aneurysm9]

Does this need to specify how to handle metrics with the '_created' suffix?

[dashpole]

Does this need to specify how to handle metrics with the '_created' suffix?

I noticed that when I looked through the spec as well. IIUC, that would give us the start timestamp of the metric, which would be helpful. I still need to think through how to use it (e.g. will we generate an additional metric with a _count suffix in exporters even if the scraped metric didn't have one?).

[reyang]

Does this need to specify how to handle metrics with the '_created' suffix?

I noticed that when I looked through the spec as well. IIUC, that would give us the start timestamp of the metric, which would be helpful. I still need to think through how to use it (e.g. will we generate an additional metric with a _count suffix in exporters even if the scraped metric didn't have one?).

This can be followed up in a separate PR if it turns out to be needed.