Make server.address and server.port to opt-in on HTTP server metrics

[lmolkova]

Fixes #108

Most HTTP server instrumentations report server.address and server.port based on the request Host header as it's the only source of information they have.

Depending on the reverse proxies presence and other infra configuration, Host header might come unmodified from clients. Malicious or buggy clients could cause a cardinality explosion and degrade the server metrics experience.

The expectation is that the majority of HTTP applications do not need server.address and server.port attributes on metrics as these attributes are static and are the same for a specific service.name or a combination of resource attributes.

They are beneficial in multi-host applications, but still, resource attributes set on the corresponding meter and tracer providers can be used to distinguish tenants.

This PR changes

• server.* requirement level to:
  • opt_in for metrics, to mitigate the attack vector
  • recommended for traces. These attributes are still interesting, but not essential for the tracing experience.
    url.query requirement level changed from recommended to required (to match url.path) on spans - this seems like a bug that slipped into BREAKING: Introduce common url.* attributes, and improve use of namespacing under http.* opentelemetry-specification#3355

[Oberon00]

url.query requirement level changed from recommended to required (to match url.path) on spans - this seems like a bug that slipped into #3355

Maybe it was accidental, but query is particularly prone to containing sensitive information, so it seems OK to be "just" recommended. I think that would allow instrumentations to provide an opt-out option which REQUIRED technically doesn't.

[trask]

@Oberon00 do you agree with making server.address and server.port Opt-In on the metrics side?

if so, I'd recommend we split out the other parts (that affect other signals) into separate PR(s)

[Oberon00]

I guess the metric changes are fine, given the cardinality constraints. Making a full URL non-constructible for traces on the server-side would be big change on the other hand: unless I'm mistaken, both the old conventions and the previous ECS-based version always made that possible with just required attributes.

[lmolkova]

I reverted all changes not related to metrics (and took the liberty to resolve corresponding threads) and will open another PR for traces (with uri.query) where we can continue the discussion.

[trask]

@arminru @jsuereth @reyang I think this is ready to merge