Support bool metrics

[psx95]

PR to add support for Bool metrics in exporter/collector.

This currently adds support for boolean valued metrics in collector exporter.

Testing

• These changes are also being tested on a newly created collector based example, this example will be added in a separate PR.

#624

[codecov]

Codecov Report

Merging #637 (b9e9250) into main (bd431a2) will increase coverage by 1.95%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #637      +/-   ##
==========================================
+ Coverage   66.44%   68.39%   +1.95%     
==========================================
  Files          36       36              
  Lines        4297     4559     +262     
==========================================
+ Hits         2855     3118     +263     
+ Misses       1314     1288      -26     
- Partials      128      153      +25     

Impacted Files	Coverage Δ
...tor/integrationtest/testcases/testcases_metrics.go	100.00% <100.00%> (ø)
exporter/collector/metrics.go	72.72% <100.00%> (+5.43%)	⬆️

... and 8 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[aabmass]

Can you add a fixture based integration test for this? It should make it really easy to test your changes against the real API as well. Directions in https://github.com/GoogleCloudPlatform/opentelemetry-operations-go/blob/main/exporter/collector/integrationtests.md

[damemi]

would it make sense to move the same kind of check that convertMetricKindToBoolIfSupported does into metricPointValueType? so then the switch statement would be something like:

switch pt {
case pmetric.NumberDataPointValueTypeInt:
  if boolUnitPresent && metricKind == metricpb.MetricDescriptor_GAUGE {
    return metricpb.MetricDescriptor_BOOL
  }
  return metricpb.MetricDescriptor_INT64
}

you could add a similar error log but it's already going to be covered by the actual data point conversion

[psx95]

But then we would have to pass all those extra parameters - kind and and unit to metricPointValueType as well.
Currently this method seems simple to me and serves a single purpose - convert pmetric.NumberDataPointValueType to its equivalent cloud monitoring type. I can see it going either way if you feel strongly about this.

[psx95]

Just removed the support for Bool metrics from non-monotonic sum (which was interpreted as GUAGE) as per the spec we have.

So now moving the check to metricPointValueType would only simplify switch statement for a single case and I feel it may not increase readability by a lot.