Document that messaging semconv are intended to cover client-side of out-of-proc messaging systems

[lmolkova]

Messaging semconv are focused on messaging clients and assume there is an out-of-proc persistent broker.

They take into account and optimize for scenarios that are only relevant to such cases, specifically:

• publish and receive calls that involve network calls, i.e. have a duration/can fail/etc
• transport-level batching
• settlement
• partitioning
• future: connection-level details, transactions

Using messaging semconv for in-memory queues or generic async processing would be an over-generalization.

• There is no generic dashboard that would apply to both - broker-based and in-memory queues. E.g. publish/receive duration/error rate, number of consumers per partition, etc, do not make sense for in-memory queues, but are essential for out of process ones
• same with visualizations like service maps, auto-analysis or alerts - they would focus on different aspects of in-mem/distributed async processing

I believe we should document that messaging semconv are applicable to messaging (broker/intermediary) scenarios and don't apply to general-purpose tasking, streaming, or p2p event-driven systems.

Such frameworks/systems may work on top of messaging and either provide an outer (to messaging) instrumentation layer, or, when/if possible, enrich messaging spans with additional framework-specific context.