Add metric.metadata for supporting additional metadata on metrics

[dashpole]

Part of open-telemetry/opentelemetry-specification#3058

Alternative to #496.

Language is borrowed from scope attributes, with the addition of: Attributes are non-identifying.

The primary motivation is to support the prometheus unknown type without explicitly adding it to the data model.

This provides a place for additional information about metrics to be provided that isn't associated with individual data points. It is non-identifying to ensure it can be safely ignored by exporters if they don't support them.

Examples of problems this could be used to solve (not proposed, just examples):

• Support additional types: prometheus.type = "unknown", or statsd.type = "set"
• Support vendor-specific features: gcp.value_type = "bool"
  • GCP currently solves this by using a "special" unit.
• Support additional features on top-of OTel: e.g. k8s.stability_level = "beta"
  • K8s currently encodes stability level in the description.

Alternatives:

• Add gauge subtype for prometheus unknown type #496
  • Pros: An enum is a smaller change. Additional attributes may cause confusion if users are looking for data point attributes.
  • Cons: Enum solves fewer use-cases, and would likely need follow-up changes for other additional types. Adding attributes (proposed here) would likely mean fewer changes to the proto in the future to support new classes of uses-cases.
• string instead of `repeated opentelemetry.proto.common.v1.KeyValue.
  • Cons: A string would make it harder to use
• attributes on Gauge instead of on Metric.
  • Pros: Meets primary use-case (prometheus unknown)
  • Cons: Likely (?) to be extended to other data types eventually, which would result in a slightly more complex protocol.
• attributes on DataPoint instead of on Metric.
  • Cons: Duplicates functionality of existing attributes field of DataPoint, and would create confusion over which to use.

@bogdandrutu @jack-berg @jsuereth @jmacd @tigrannajaryan

[carlosalberto]

It seems we are good to go, specially after 1.1.0 was released. @bogdandrutu maybe a last look?

[carlosalberto]

I think we are ready to merge (briefly mentioned this in the Spec call a week or two ago, and no reviews ever since).

cc @bogdandrutu