Fix metadata fetching when metrics differ by trimmable suffixes

[dashpole]

Description:
Fix incorrect merging of metric metadata when metrics differ by trimmable suffixes. Additionally, remove unnecessary interfaces, and simplify the implementation of metadata fetching to make it more readable.

To fix the bug, first always check for metadata using the original metricName first. We need to do this both when looking up the metric family (in metricsbuilder.go), and when looking up metadata when constructing the initial metric family. Second, add the includesMetric() function to metricFamily, which ensures that we only merge metrics under types that include multiple series. For example, if there is an existing family my_metric, which is a gauge, it does not include metrics my_metric + suffix.

To make the newMetricFamily function more readable, split out a metadataForMetric function, which is shared between pdata/opencensus implementations. This allows us to return early once we have found metadata for the metric, and reduces the number of else statements (and nesting) needed to handle all cases correctly. Also, use a map to store internal metric metadata to avoid needing to recreate the same MetricMetadata frequently for internal metrics.

Link to tracking Issue:
Fixes #6931

Testing:

As described in #6931, the comment prior to python_gc_collections_total isn't correct, so I added metadata for counter_test_total in the metadata table.

I added metadata for poor_name to the testing metadata cash. Prior to the fixes in this PR, this would cause tests to fail by making poor_name_count be incorrectly renamed to poor_name and come out as a gauge.

@Aneurysm9 @gracewehner

[gracewehner]

Thanks @dashpole for finding and fixing this!

For python_gc_objects_collected_total, when adding some debug lines I still see the mc.Metadata(metricName) lookup fail unless it's only looking for python_gc_objects_collected, even though the #TYPE and #HELP hints include _total:
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/32a4474c8031da873b8d48ef793c5bb93cf0a878/receiver/prometheusreceiver/internal/metricfamily.go#L48 I am still not sure why it behaves like that for the default python counters...

However the metric is still sent with these changes since it then follows this code path: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/32a4474c8031da873b8d48ef793c5bb93cf0a878/receiver/prometheusreceiver/internal/metricfamily.go#L57-L61

I think it'll be considered a gauge though instead of a counter because of: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/32a4474c8031da873b8d48ef793c5bb93cf0a878/receiver/prometheusreceiver/internal/metricsbuilder.go#L252-L253

[jpkrohling]

I believe this is an improvement, but it would be good to address @gracewehner's point before merging.

[dashpole]

Figured out what the discrepancy was from. I think the prometheus server (and thus, the otel collector) add openmetrics headers by default: https://github.com/prometheus/prometheus/blob/27343277fa47465e54799e2a0a5356febe697c29/scrape/scrape.go#L761.

If I curl my python client with: curl -v localhost:8000/metrics/ --header "Accept: application/openmetrics-text", I get

...
< Content-Type: application/openmetrics-text; version=0.0.1; charset=utf-8
< Content-Length: 2098
<
# HELP python_gc_objects_collected Objects collected during gc
# TYPE python_gc_objects_collected counter
python_gc_objects_collected_total{generation="0"} 101.0
python_gc_objects_collected_total{generation="1"} 273.0
python_gc_objects_collected_total{generation="2"} 0.0
...

I'll make sure we can handle that case properly

[dashpole]

Now i'm trying to figure out what to do with this... If metric metadata is sent without a type suffix, it would seem strange to add it here, but that is what the previous behavior was.

[dashpole]

I'm keeping the current behavior for now, even though it seems strange to me.

Dismissing as the PR got updated.

[jpkrohling]

@dashpole, once this is ready for another review, please notify @gracewehner as well.

[dashpole]

@gracewehner I think i've resolved your concern above. It now correctly handles the openmetrics case above