Preserve unknown, info, and stateset metric types from prometheus receivers to exporters

[dashpole]

Description:

Preserve the original prometheus metric type using metric.metadata, as described in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#metric-metadata

Prometheus TYPE metadata, if present, MUST be used to determine the OTLP data type, and dictates type-specific conversion rules listed below. Metric families without type metadata follow rules for unknown-typed metrics below. The TYPE metadata MUST also be added to the OTLP metric.metadata under the prometheus.type key (e.g. prometheus.type="unknown").

From https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/prometheus_and_openmetrics.md#gauges-1

An OpenTelemetry Gauge MUST be converted to a Prometheus Unknown-typed metric if the prometheus.type key of metric.metadata is unknown. Otherwise, it MUST be converted to a Prometheus Gauge.

If the aggregation temporality is cumulative and the sum is non-monotonic and the prometheus.type key of metric.metadata is info, it MUST be converted to an OpenMetrics Info metric.
If the aggregation temporality is cumulative and the sum is non-monotonic and the prometheus.type key of metric.metadata is stateset, it MUST be converted to an OpenMetrics StateSet metric.

Link to tracking Issue:

Fixes #16768

Fixes open-telemetry/prometheus-interoperability-spec#69

Testing:

Updated unit tests.

Note

The prometheus exporter uses the prometheus client library, which does not support info or stateset metric types, so the prometheus exporter only preserves unknown-typed metrics.

[aknuds1]

LGTM