Messaging: clarify network attributes usage on common semconv

[lmolkova]

Changes

Addresses messaging portion of #690

Removes network.transport|type attributes from general messaging semantic conventions.

Based on the findings from Java instrumentation libraries, the only messaging instrumentation that populates network attributes is RabbitMQ (which also sets them in native .NET instrumentation).

This PR clarifies that network.server.address|port should be only set when they represent a specific broker instance (when individual instances are visible from the application side) and recommends to use them on the RabbitMQ (as one of the systems that's usually self-hosted)

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml

[pyohannes]

From the messaging point of view, I'd agree to merge those changes.

[trask]

it would be great to look over the existing Java database instrumentations to see how many places where we're (usefully/correctly?) capturing network attributes

[lmolkova]

Looking into java instrumentation repo:

Messaging systems:

• report only network attributes:
  • rabbitmq, but reporting network stuff is not straightforward involving thread locals, passing things through otel context
• report server and network attributes:
  • aws sns/sqs server and only network.protocol.verion out of all network attributes
• report server attributes only:
  • pulsar
• report no server/network attributes at all: kafka, rocketmq

Databases:

• report only network:
  • cassandra
  • Redisson
• report only server:
  • jdbc
  • mongo
  • r2
  • vertxsql
  • elastic rest
• report both, server and network attributes:
  • dynamodb (also reports network.protocol.verion, but no other network)
  • jedis (depends on the version)
  • lettuce
  • vertx redis
  • elastic-transport
  • opensearch
• report nothing (no network or server): geodedb, Rediscala, Spymemcached

All instrumentations that report network, report only network.peer.address|port and some report network.type. I could not find any that reports protocol name or transport.

I probably missed something, but I think there is enough evidence.

• server.* or network attributes cannot be required on DB or messaging
• I think instrumentations that support network, but don't report server.address should try by calling getHostName() on Inet*Address they already have
• I still want to remove network from general db, but keep it for redis, cassandra, and elastic.
• I still want to remove network from general messaging, but want to keep them for rabbitmq

[pyohannes]

Looking into java instrumentation repo:

Thanks @lmolkova for this research.

To add one more datapoint, the .NET RabbitMQ instrumentation populates both network and server attributes (if they are available):

• network.peer.address
• network.peer.port
• network.local.address
• network.local.port
• network.type
• network.protocol.name
• network.protocol.version
• server.address
• server.port

[lmolkova]

Based on the discussion in Messaging SIG, breaking this one down into two PRs. This one contains messaging portion only.

Will send a separate one for DBs.

[lmolkova]

Based on the database discussion on similar PR #768 (comment), I updated this one to be consistent with databases:

• removed network.transport|type
• kept network.peer.* in common, but clarified they apply for self-hosted systems where they make sense

@open-telemetry/semconv-messaging-approvers please re-review