Change network.transport from recommended to opt-in in the HTTP semconv

[trask]

Fixes #389

network.transport is typically derivable from network.protocol.version:

• HTTP 1.0, 1.1, 2 --> tcp
• HTTP 3 --> udp

so it doesn't provide much value to capture in HTTP semconv.

Changes

Change network.transport from recommended to opt-in in the HTTP semconv.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions.

[mateuszrzeszutek]

👍

It was pretty much always skipped anyway:

If not default (tcp for HTTP/1.1 and HTTP/2, udp for HTTP/3).

[Oberon00]

network.transport is always derivable from network.protocol.version:

Actually this is not true. In Node.js scenarios I think it is not entirely unheard of to communicate with a local HTTP server over Unix domain sockets. We have seen this in the wild with our agents I believe

[lmolkova]

Actually this is not true. In Node.js scenarios I think it is not entirely unheard of to communicate with a local HTTP server over Unix domain sockets. We have seen this in the wild with our agents I believe

Looking for net.transport in -js and -js-contrib repos, I don't see HTTP instrumentations using it:

• http instrumentations set tcp or udp only
• node:net (IPC) module instrumentation sets pipe or UNIX domain socket. I.e. it'd probably create more spans for the underlying socket if HTTP calls happen over it.

I agree it's a valid concern, but having this attribute outside of HTTP spec and effectively opt-in still works.
Instrumentations can add it later, it would not even be breaking for metrics - from the format of the server.address it's pretty clear it's a unix domain socket and adding transport would not create new time series.