#2703 define guidance for rpc protocol vs framework

[thompson-tomo]

Progresses #2703

Changes

This seeks to adopt system specific naming for the rpc namespace by first defining the replacement attributes (rpc.transport.protocol.name & rpc.framework.name) as well as what the requirements are to be considered a well known value for that attribute.

The usage of these attributes would be as follows:

• rpc.transport.protocol.name: required
• rpc.framework.name: recommend when a framework is being used

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

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]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[KalleOlaviNiemitalo]

In some other semconv issues, streaming was mentioned. That reminded me about Blocks Extensible Exchange Protocol (BEEP, IETF RFC 3080), which has streaming responses: you send a MSG message, and then get back any number of ANS messages and finally a NUL message. BEEP however does not define any protocol elements for method names or arguments — message payloads just consist of bytes — so in the terminology of this PR, it's a network protocol (like HTTP), rather than an RPC protocol or an RPC framework. One can run SOAP over BEEP, as per IETF RFC 4227.