Delete idea of "accumulation" from metrics SDK

[jack-berg]

The metrics SDK has an unnecessary level of abstraction called "accumulation". When metrics are collected, we:

• Iterate through SdkMeters, and for each:
• Iterate through all the MetricStorages, and for each:
• Iterate through all the AggregatorHandles (one per attributes), and for each:
• doAccumulateAndMaybeReset
• Transform accumulations to PointData
• Create MetricData from PointDatas, Resource, InstrumentationScopeInfo, etc.

An accumulation is essentially a PointData without attributes, or start / end time. We can get rid of accumulation by adjusting AggregatorHandle to return PointData instead. In doing so we reduce complexity and allocations.

This is a pretty invasive change, since it requires changing method signatures to pass around startEpochNanos and epochNanos where not previously needed. To do it right, I also needed to change the vocabulary of the SDK, renaming any references to accumulation in method names or variables to more appropriate names.

Its cumbersome to review, but is a strict refactor so can lean on the tests. It will ultimately make the metrics SDK easier to understand / maintain and more performant, so I do think it's a worthwhile addition.

[codecov]

Codecov Report

Base: 91.19% // Head: 91.01% // Decreases project coverage by -0.19% ⚠️

Coverage data is based on head (efc98fb) compared to base (eca5ce0).
Patch coverage: 91.81% of modified lines in pull request are covered.

❗ Current head efc98fb differs from pull request most recent head e2ab7c0. Consider uploading reports for the commit e2ab7c0 to get more accurate results

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5154      +/-   ##
============================================
- Coverage     91.19%   91.01%   -0.19%     
+ Complexity     4939     4880      -59     
============================================
  Files           551      545       -6     
  Lines         14617    14498     -119     
  Branches       1402     1383      -19     
============================================
- Hits          13330    13195     -135     
- Misses          891      908      +17     
+ Partials        396      395       -1     

Impacted Files	Coverage Δ
...ry/sdk/metrics/internal/aggregator/Aggregator.java	33.33% <0.00%> (-54.17%)	⬇️
...sdk/metrics/internal/state/EmptyMetricStorage.java	0.00% <ø> (ø)
...etry/sdk/metrics/internal/state/MetricStorage.java	0.00% <ø> (ø)
...trics/internal/state/SynchronousMetricStorage.java	72.72% <ø> (ø)
.../sdk/metrics/internal/view/DefaultAggregation.java	80.00% <ø> (ø)
...try/sdk/metrics/internal/view/DropAggregation.java	80.00% <ø> (ø)
...ernal/view/ExplicitBucketHistogramAggregation.java	100.00% <ø> (ø)
...internal/view/ExponentialHistogramAggregation.java	100.00% <ø> (ø)
...dk/metrics/internal/view/LastValueAggregation.java	75.00% <ø> (ø)
...etry/sdk/metrics/internal/view/SumAggregation.java	90.90% <ø> (ø)
... and 25 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jkwatson]

A lot to review here. As long as it's functionally the same, I'm definitely in favor of removing an extra layer of complexity and a net 150 lines less code is always a win.