support exact kind in OTLP metrics exporter

[hstan]

When using exactSelector we found that the OTLP exporter does not handle array aggregator's kind (ExactKind).
This PR tries to fix it.

[hstan]

@jmacd seen from the failed test, I noticed it's explicitly asserted this shuold not be supported https://github.com/open-telemetry/opentelemetry-go/blob/master/exporters/otlp/internal/transform/metric_test.go#L349

I'm not sure why is that, does this change makes sense at all?

[MrAlias]

@jmacd seen from the failed test, I noticed it's explicitly asserted this shuold not be supported https://github.com/open-telemetry/opentelemetry-go/blob/master/exporters/otlp/internal/transform/metric_test.go#L349

I'm not sure why is that, does this change makes sense at all?

The change seems to make sense to me. If you configure the metrics telemetry pipeline to send exact values they should not error the exporter. The tests will need to be updated as part of this PR.

opentelemetry-go/exporters/otlp/internal/transform/metric_test.go

Lines 351 to 353 in 187adeb

	require.Error(t, err)
	require.Nil(t, mpb)
	require.True(t, errors.Is(err, ErrUnimplementedAgg))

[codecov]

Codecov Report

Merging #1309 (910bbd5) into master (c857a3d) will increase coverage by 0.0%.
The diff coverage is 85.3%.

@@          Coverage Diff           @@
##           master   #1309   +/-   ##
======================================
  Coverage    77.5%   77.5%           
======================================
  Files         125     125           
  Lines        6090    6131   +41     
======================================
+ Hits         4720    4753   +33     
- Misses       1119    1127    +8     
  Partials      251     251           

Impacted Files	Coverage Δ
exporters/otlp/internal/transform/metric.go	80.1% <85.3%> (+<0.1%)	⬆️

[MrAlias]

👍

[hstan]

@MrAlias
I think the build failed due to a flaky test, I've no permission to rerun (passed locally)

[jmacd]

(Sorry all, I will catch up with this PR later today!!)

[jmacd]

To be explicit, it is sensible and correct to expose exact values as Gauge data points.
We will eventually have a specification that states this behavior. 😀
Thanks 💪.

[jmacd]

I see a connection with open-telemetry/opentelemetry-proto#188. There's no way to know that the resulting Gauge data points represent raw data, but I would like there to be.

[Aneurysm9]

Apologies, this appears to be tripped up by a change to package structure, likely #1321.