[Tower] HTTP Server Metrics Stabilization

[francoposa]

Tracking issue for tasks related to stabilizing the tower-instrumentation crate

High-level aims for stabilization from CNCF Slack discussion:

• public api should be stable (i.e no more breaking changes)
• conformance with OTel semantic conventions.
• performance tested
• test coverage. (bit ambitious goal is to use weaver live-check to prove we are producing telemetry in compliance with OTel conventions)

API Stability & Semantic Conventions
Keeping these together as they are intertwined - the majority of public API surface is in the configuration options largely used to comply with or opt out of the semantic conventions.

• Default histogram bucket bounds to semantic conventions
• [Tower] Fix span name generation and configuration options to prevent cardinality explosion from http.route #527
• Rename HTTPLayer to HTTPServerLayer or similar to clear namespace for later tower client layer

Correctness & Performance Testing
TODO task list - possibly something that is more of a repo-wide setup than specific to this crate

Open Questions

• Any concerns about pushing towards stabilizing tracing when it has only just been merged? How long should we wait?
  • We could look at tracking the milestones separately, with aiming to stabilize HTTP Server metrics first

[cijothomas]

Any concerns about pushing towards stabilizing tracing

OTel Rust upstream is not stable for tracing, so we need to hold until that is stable. We can surely stabilize the metrics part alone.

[cijothomas]

open-telemetry/opentelemetry-rust#3371 (comment) To not lose track of this perf tip.