Add attributes advice API (just DoubleCounter for now)

[mateuszrzeszutek]

Implements open-telemetry/opentelemetry-specification#3546

I only added implementation for the DoubleCounter in this PR; I'll extend it to all other instruments in the following PR if this one is accepted.

[codecov]

Codecov Report

Patch coverage: 94.23% and project coverage change: +0.02% 🎉

Comparison is base (ea7b761) 91.25% compared to head (16fc3d4) 91.28%.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5677      +/-   ##
============================================
+ Coverage     91.25%   91.28%   +0.02%     
- Complexity     5032     5042      +10     
============================================
  Files           556      558       +2     
  Lines         14861    14890      +29     
  Branches       1389     1392       +3     
============================================
+ Hits          13562    13592      +30     
+ Misses          896      894       -2     
- Partials        403      404       +1     

Files Changed	Coverage Δ
...ncubator/metrics/ExtendedDoubleCounterBuilder.java	0.00% <0.00%> (ø)
...ntelemetry/sdk/metrics/SdkDoubleUpDownCounter.java	100.00% <ø> (ø)
...opentelemetry/sdk/metrics/SdkLongGaugeBuilder.java	100.00% <ø> (ø)
...emetry/sdk/metrics/internal/descriptor/Advice.java	84.61% <81.81%> (-15.39%)	⬇️
...lemetry/sdk/metrics/AbstractInstrumentBuilder.java	100.00% <100.00%> (ø)
...io/opentelemetry/sdk/metrics/SdkDoubleCounter.java	100.00% <100.00%> (ø)
.../opentelemetry/sdk/metrics/SdkDoubleHistogram.java	100.00% <100.00%> (ø)
...io/opentelemetry/sdk/metrics/SdkLongHistogram.java	100.00% <100.00%> (ø)
...trics/internal/view/AdviceAttributesProcessor.java	100.00% <100.00%> (ø)
...emetry/sdk/metrics/internal/view/ViewRegistry.java	97.97% <100.00%> (+0.20%)	⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[breedx-splk]

Looks good to me.

[jack-berg]

Looks good, just one small edge case to think about in ViewRegistry

[jack-berg]

Hey so I made a comment over in the spec which states:

Just so we're clear, my interpretation is that because advice is non-identifying, two histograms with the same identity and different advices will result in 1 metric stream. And thus we have to pick one set of advice to apply to the resulting metric stream, which should naturally be the first we see.

But that isn't the case as implemented today (and also not for the histogram bucket advice). You can demonstrate this by creating another counter with the same name, and with no advice, and seeing that there are two metrics produced instead of just one:

    DoubleCounter counter2 = meterProvider.get("meter").counterBuilder("counter").ofDoubles().build();
    counter2.add(1, ATTRIBUTES);

The issue stems from MetricStorageRegistry#register(MetricStorage), a tricky little piece of code responsible for evaluating whether a newly registered instrument should get a new storage (and thus a new metric stream at collection) or should send its measurements to an existing storage (and thus merge with an existing metric stream at collection).

The problem is that we use MetricDescriptor.equals(..) to determine if an existing storage matches, but that is a pretty strict equality, checking equality of name, description, view, InstrumentDescriptor (including name, description, unit, type, value type, and advice), and aggregation name.

And I believe there's a bug where if a instrument matches except the case of the name, we produce two metric streams, instead of one like I thought we did. See spec issue #3626.

I think this is probably fine for this PR. I need to go back and fix MetricStorageRegistry#register in a more general capacity.

[jack-berg]

Opened #5683 to discuss.

[mateuszrzeszutek]

Yeah, I 100% agree advice should be non-identifying.

I think this is probably fine for this PR. I need to go back and fix MetricStorageRegistry#register in a more general capacity.

👍

[jack-berg]

Solved in #5701.

[mateuszrzeszutek]

@jack-berg Is this ready to merge?