Add the internal experimental metric feature package

[MrAlias]

Used to enable specification defined features. Such as:

• Add cardinality limiting to the metric SDK as an experimental feature #4457
• Add exemplars to the metric SDK as an experimental feature #4455

This is the first step in adding these features.

[codecov]

Codecov Report

Merging #4715 (ec66f05) into main (9ccb0c6) will increase coverage by 0.0%.
The diff coverage is 100.0%.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #4715   +/-   ##
=====================================
  Coverage   81.9%   82.0%           
=====================================
  Files        224     225    +1     
  Lines      18208   18239   +31     
=====================================
+ Hits       14930   14961   +31     
  Misses      2989    2989           
  Partials     289     289           

Files	Coverage Δ
sdk/metric/internal/x/x.go	100.0% <100.0%> (ø)

[dashpole]

Did you consider modeling this after feature-gates in the collector? https://github.com/open-telemetry/opentelemetry-collector/tree/main/featuregate. If we used it directly, it would mean collector users could configure OTel Go's feature gates using the collector's feature-gates flag, which would be neat. We would have to wait for the v1 release to avoid a circular unstable dependency.

Assuming we don't want to depend on it directly, could we follow the same pattern, and use a OTEL_GO_FEATURE_GATES env var with k0=v0,k1=v1 format, and defined stages? Or is that overkill?

[MrAlias]

Did you consider modeling this after feature-gates in the collector? https://github.com/open-telemetry/opentelemetry-collector/tree/main/featuregate. If we used it directly, it would mean collector users could configure OTel Go's feature gates using the collector's feature-gates flag, which would be neat. We would have to wait for the v1 release to avoid a circular unstable dependency.

Assuming we don't want to depend on it directly, could we follow the same pattern, and use a OTEL_GO_FEATURE_GATES env var with k0=v0,k1=v1 format, and defined stages? Or is that overkill?

I haven't looked at this yet. I'll be sure to take a look.

One question I have though, is how will uses distinguish between their SDK features and collector features? For example, given we will support different features than the collector but a user may define them in the same environment variable does that mean we need to drop unknown? Do we log this error?

[dashpole]

One question I have though, is how will uses distinguish between their SDK features and collector features? For example, given we will support different features than the collector but a user may define them in the same environment variable does that mean we need to drop unknown? Do we log this error?

We would have to decide how to handle errors from parsing the flags, including when users set feature gates that don't exist. Writing to the global error handler seems reasonable.

[MrAlias]

@dashpole I don't see in that linked package where the environment variable OTEL_GO_FEATURE_GATES is supported. Is this an extension somewhere, or am I just bad at searching?

[MrAlias]

@dashpole does featuregate support processing configuration? That was an ask from here that I think is useful.

We would need to support additional environment variables if it does right? Or could we add it to that package?

[dashpole]

It does not support configuration. We would need additional env vars or something else.

[dashpole]

I don't see in that linked package where the environment variable OTEL_GO_FEATURE_GATES is supported. Is this an extension somewhere, or am I just bad at searching?

We would have to add that. It only supports flags today. Or, we could require users to register flags to use it, which has the advantage of making users decide how to handle parsing failures (so they don't need to use the global error handler)

[pellared]

Can we add tests?