Use OTel semconv package instead of consts

[sahidvelji]

The telemetry package should probably use the OTel semconv package for the consts below. The benefit of doing so is that updates to the semconv would generally require minimal changes to the telemetry package. Since the constants are already defined there, it does not make sense to redefine them in the telemetry package.

See the consts defined under the "feature_flag" namespace: https://pkg.go.dev/go.opentelemetry.io/otel@v1.37.0/semconv/v1.34.0#section-readme:~:text=Namespace%3A%20feature_flag

go-sdk/openfeature/telemetry/telemetry.go

Lines 27 to 36 in d7174f7

	FlagKey string = "feature_flag.key"
	ErrorTypeKey string = "error.type"
	ResultValueKey string = "feature_flag.result.value"
	ResultVariantKey string = "feature_flag.result.variant"
	ErrorMessageKey string = "error.message"
	ContextIDKey string = "feature_flag.context.id"
	ProviderNameKey string = "feature_flag.provider.name"
	ResultReasonKey string = "feature_flag.result.reason"
	FlagSetIDKey string = "feature_flag.set.id"
	VersionKey string = "feature_flag.version"

[beeme1mr]

Yes, this is a good idea. I'm in favor of this.

[toddbaert]

Fully support. We do this elsewhere.

[sahidvelji]

So after looking into this more closely, I don't think we should be returning map[string]string. Users would use the feature_flag consts defined in the semconv package to key into the map. But these are of type attribute.Key. So a user would need to do event[string(semconv.FeatureFlagResultReasonKey)], where event is the map. This is cumbersome and also requires the user to convert the map to attribute.KeyValue in order to use the values with OTel. I think it is reasonable to assume that if someone uses OpenFeature, they also use OpenTelemetry. Instead of returning a map, it's much more convenient to return []attribute.KeyValue. Then if there is a need to key into the slice of attributes, the user would use attribute.NewSet in order to first create a Set to use Set.Value. I can create a PR to showcase what this would look like, but essentially this means that the telemetry package provides first-class OTel support by returning attribute.KeyValue pairs.

If we go ahead with this proposal as-is, we would be using the semconv attribute.Keys and then converting those to string for each key because we need to return map[string]string. Then the user would use the semconv attribute.Keys to key into the map by also having to convert to attribute.Key to string first. This is rather backwards, and so we should be returning OTel-compatible attributes directly. The attribute package has builtin support for operations on attributes including filtering and getting values.

[sahidvelji]

Please see #418