Database/Messaging extensions: revise extends in yaml

[lmolkova]

Came up in #359 (comment).

UPDATE: based on the discussion in Semconv WG:

• we need to revisit individual database semconv and check if they should extend base db conventions in yaml.
• if some of the recommended generic attributes do not apply to specific DB, extensions should not extend base one and should rather reference all applicable attributes
• based on this we can also restructure generic DB conventions and adjust requirement levels

The context:

Elasticsearch semconv extends db in yaml, but re-referenced attributes in the server.* namespace, so it's unclear what was the original intent and what the actually full semconv should be:

Option 1:

If Elastic should only report attributes currently defined/referenced in yaml (without extending db), then all the attributes are

<!-- semconv db.elasticsearch -->

Attribute
db.elasticsearch.cluster.name
db.elasticsearch.node.name
db.elasticsearch.path_parts.<key>
db.operation
db.statement
http.request.method
server.address
server.port
url.full

Option 2:

If elasticsearch should extend DB, then it implicitly includes the following attributes (if a full MD table is rendered)

<!-- semconv db.elasticsearch(full) -->

Attribute
db.connection_string
db.elasticsearch.cluster.name
db.elasticsearch.node.name
db.elasticsearch.path_parts.<key>
db.jdbc.driver_classname
db.name
db.operation
db.statement
db.system
db.user
network.transport
network.type
server.address
server.port
server.socket.address
server.socket.domain
server.socket.port
url.full

[lmolkova]

/cc @estolfo

[lmolkova]

I believe we should provide all the applicable attributes in the system-specific md tables for all databases and messaging extensions.

It would provide clarify to the readers and instrumentation authors and allow semconv authors to document system-specific things about the attributes.

[trask]

@lmolkova is this now a duplicate of #869?

[lmolkova]

yes, #869 is wider than this one. Let's close this one.