Remove metric processor Subtract function; rename ExportKind to AggregationTemporality

[jmacd]

The basic Processor has code to convert cumulative values to delta values on the export path. This was exploratory functionality, and has been requested a few times, but is not considered widely useful. This removes it completely.

There are not many known use-cases for this support for it to be included in the basic processor, but for example:

• Metric backend prefers DELTA to GAUGE data for SumObserver or UpDownSumObserver. For example, monitor change in process.cpu.time as a DELTA not a CUMULATIVE.
• Metric exporter configures label removal an UpDownSumObserver instrument, with say 2 dimensions input by the observer callback and 1 dimension output (using Histogram type); then configures exemplar output (using RawValue type) with the complete two dimensions; exemplar sampling should be performed using DELTA weights to select the items most responsible for the rise/fall of the sum.

As you can see these are a bit contrived, and I think the exporters that want these things can easily take a DIY approach.

This PR also renames ExportKind to AggregationTemporality, as this terminology was already flagged as confusing in an open spec PR: open-telemetry/opentelemetry-specification#1159 (comment)

[codecov]

Codecov Report

Merging #1415 (e7ab9a2) into main (38efc87) will decrease coverage by 0.0%.
The diff coverage is 84.7%.

@@           Coverage Diff           @@
##            main   #1415     +/-   ##
=======================================
- Coverage   79.0%   78.9%   -0.1%     
=======================================
  Files        127     127             
  Lines       6683    6666     -17     
=======================================
- Hits        5280    5262     -18     
  Misses      1148    1148             
- Partials     255     256      +1     

Impacted Files	Coverage Δ
exporters/otlp/internal/otlptest/data.go	61.7% <ø> (ø)
exporters/otlp/options.go	100.0% <ø> (ø)
exporters/otlp/otlpgrpc/driver.go	90.1% <ø> (ø)
exporters/otlp/otlphttp/driver.go	93.5% <ø> (ø)
exporters/otlp/protocoldriver.go	100.0% <ø> (ø)
exporters/stdout/metric.go	76.3% <0.0%> (ø)
sdk/export/metric/aggregation/aggregation.go	100.0% <ø> (ø)
sdk/export/metric/metrictest/test.go	19.3% <ø> (ø)
sdk/metric/aggregator/sum/sum.go	89.4% <ø> (+10.9%)	⬆️
sdk/metric/controller/basic/controller.go	93.2% <ø> (ø)
... and 10 more

[jmacd]

@open-telemetry/specs-metrics-approvers As I am trying to bring the OTel-Go metrics SDK into line with "Everything we will specify", this is something I'd like to remove. (Note: I'm hoping to relieve the @open-telemetry/go-approvers of this responsibility, it's just code deletion.)

[evantorrie]

What was an example use-case for this functionality? Something like an absolute system counter (# of network packets sent) that the backend system wants exposed as a delta?

I presume this does not affect any synchronous instruments, which will still support being exported as a delta even if they are an absolute count?

[jmacd]

Yes @evantorrie something like that. I updated the PR description to clarify some use-cases, but I think the term confusion has a lot to do with "ExportKind", which I've renamed as we have already discussed in an open spec PR (open-telemetry/opentelemetry-specification#1159 (comment)).

The DeltaExportKind still exists, so there could be a 3rd party Processor that actually supports converting precomputed sums to delta.

@krnowak Yes, but I don't really think there are any of these out there. An exporter could use ConstantExportKindSelector(DeltaExportKind) and a custom processor could implement it, but it's more complexity than the case processor deserves.

[jmacd]

@bogdandrutu Please review.

[jmacd]

PTAL

[jmacd]

@bogdandrutu please take a look.

[MrAlias]

Closing as the metrics signal refactor at the specification level might make this work wasted. We can open again if the specification solidifies and it is determined needed.