Determine the structure for Metrics instrumentation

[kaylareopelle]

Metrics are still veryyy experimental, but, for those willing to take the risk, I'd like to start building instrumentation that can emit metrics.

Before we can do that, we need to decide how to keep the stable traces code safe from experimental metrics.

Current ideas:

• More than one condition needs to be true to turn on metrics (show that you really really want this)
  • First requirement: The presence of the Metrics API is detected
  • Second requirement: The configuration enables metrics
• Only emit HTTP metrics that

Potential approaches:

• Similar to the ConfigurationPatch that allows the Metrics SDK to use the Configurator, create a separate module that only gets loaded if the conditions to enable metrics are met
• Put conditionals everywhere to check to see if metrics should be generated
• Create separate libraries to emit metrics (not a huge fan on this one)

[kaylareopelle]

Some ideas:
#1128 - Puts conditions all over the place to check for the right conditions to send metrics
#1129 - Load the metrics-related code only if certain conditions are met

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

[kaylareopelle]

Todo:

• Refactor so that metrics duration, attributes are not directly copied off the span
• Create a separate handler for metrics
• Prototype the meter configurator to control sending metrics/traces