Return the same agg for identical instruments

[MrAlias]

From the specification:

Based on the recommendations from the data model, the SDK MUST aggregate data from identical Instruments together in its export pipeline.

Since identical "describes instances where all identifying fields are equal" and the identifying fields are:

• The name of the Instrument
• The kind of the Instrument - whether it is a Counter or one of the other kinds, whether it is synchronous or asynchronous
• An optional unit of measure
• An optional description
• note: we do not currently support advice so it is not considered here

And the cache look up key:

opentelemetry-go/sdk/metric/pipeline.go

Line 326 in 135c64f

cv := i.aggregators.Lookup(id, func() aggVal[N] {

is missing the instrument kind, and contains the additional aggregation name, monotonicity, temporality, and number:

opentelemetry-go/sdk/metric/instrument.go

Lines 152 to 171 in 135c64f

	// streamID are the identifying properties of a stream.
	type streamID struct {
	// Name is the name of the stream.
	Name string
	// Description is the description of the stream.
	Description string
	// Unit is the unit of the stream.
	Unit string
	// Aggregation is the aggregation data type of the stream.
	Aggregation string
	// Monotonic is the monotonicity of an instruments data type. This field is
	// not used for all data types, so a zero value needs to be understood in the
	// context of Aggregation.
	Monotonic bool
	// Temporality is the temporality of a stream's data type. This field is
	// not used by some data types.
	Temporality metricdata.Temporality
	// Number is the number type of the stream.
	Number string
	}

The OTel Go implementation is not compliant:

• If two different instruments with the same, name, unit, kind, and description but of different number types (i.e. int64 and float64) are created they will use different aggregators

Originally posted by @MrAlias in #3653 (comment)

[MadVikingGod]

The spec says:

Language-level features such as the distinction between integer and floating point numbers SHOULD be considered as identifying.

Wouldn't an int counter be different from a float counter of the same name, and should get different aggregators because of that?

[MrAlias]

For the API sure, but the data-model conflicts with this:

Within certain data point types (e.g., Sum and Gauge) there is variation permitted in the numeric point value; in this case, the associated variation (i.e., floating-point vs. integer) is not considered identifying.

And the SDK spec references the data-model not the API here.

[MrAlias]

I think the specification needs to be changed here.

[MrAlias]

open-telemetry/opentelemetry-specification#3585

[MrAlias]

open-telemetry/opentelemetry-specification#3585 clarified the identifying fields to be:

• name
• instrument kind
• unit
• description
• language-level features such as the number type (int64 and float64)

Based on this, the cache key needs to be updated to include the instrument kind and drop the aggregation name, monotonicity, and temporality.

note: the name matching is still being done in a case-sensitive manner. This is still an open question: open-telemetry/opentelemetry-specification#3539