Add `Context` parameter to Enabled for metrics instruments

[pellared]

We should add Context as a parameter similarly to https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md#enabled.

Context is needed for allowing "context related" behavior. For instance, it enables to user to disable the instrument for some key/value in the context has been set. It can also used to see if the call is within a span. Related PR: #4203

Created here.

[jack-berg]

Why?

[pellared]

Why?

Description updated. Thanks

[jack-berg]

There's no corresponding SDK behavior that would allow the enabled API to change its response based on context.

[pellared]

There's no corresponding SDK behavior that would allow the enabled API to change its response based on context.

A custom API implementation (e.g. SDK wrapper) could change its response based on context.
The SDK can add such behavior in future.

I find that adding is important for Go that require passing Context explicitly. Adding it later to the API would be a burden.
For reference: https://go.dev/wiki/CodeReviewComments#contexts.

CC @open-telemetry/go-maintainers, @open-telemetry/collector-maintainers

[svrnm]

@open-telemetry/technical-committee since there is precedence for this already, we think that we can move forward with this, any objections? (cc @pellared @jpkrohling @danielgblanco)

[mx-psi]

Agree with @pellared that adding this is important for Go

[jmacd]

IMO there is no need to modify the specification here.

To me, this is a Go-specific question. Golang uses explicit context, and all API calls should have context independent of whether OTel specifications explicitly mention context. There is no need to modify the OTel specification to add a Context parameter in Golang. Most OTel APIs rely on implicit context, like being able to get a thread-local context object. Golang does not have thread-local state, so we always expect a Context argument.

It shouldn't require a lot of imagination to see how context is useful for customized SDK purposes. A custom metric SDK could record metric events to the active span when the context is sampled, for example.

[pellared]

OTel APIs rely on implicit context

This is why in almost all places Context is added as required for languages requiring explicit context. I would prefer to have the specification consistent.