feat!: only emit stable http, network and database attributes

[maryliag]

Part Of open-telemetry/opentelemetry-js#6240

• Only emit stable HTTP, network and Database attributes.
• Remove config that allow to send old metrics
• Update documentation
• Cleanup removing functions, files and sem conv no longer used

Affected packages:

• instrumentation-amqplib
• instrumentation-aws-sdk
• instrumentation-cassandra-driver
• instrumentation-document-load
• instrumentation-hapi
• instrumentation-ioredis
• instrumentation-knex
• instrumentation-memcached
• instrumentation-mongodb
• instrumentation-mongoose
• instrumentation-mysql
• instrumentation-mysql2
• instrumentation-nestjs-core
• instrumentation-net
• instrumentation-pg
• instrumentation-redis
• instrumentation-tedious
• sampler-aws-xray

[Copilot]

Pull request overview

Copilot reviewed 106 out of 106 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 106 out of 106 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 106 out of 106 changed files in this pull request and generated 1 comment.

[overbalance]

Browser 👌
Two suggestions and a question: Should we be importing attributes in test files or hardcoding the values when asserting? Hardcoding seems safer. I see a mix of both already...

[maryliag]

Should we be importing attributes in test files or hardcoding the values when asserting?

The majority uses the attributes from semconv, so I tried to keep it that way

[pichlermarc]

Thank you for working on this. 🎉

I see db.client.connections.usage (which is deprecated) is still emitted by @opentelemetry/instrumentation-mysql and @opentelemetry/instrumentation-mongodb - but the replacement metric db.client.connection.count is still in-development.

WDYT: Should we just unconditionally emit db.client.connection.count instead like @opentelemetry/instrumentation-pg already does? Seems to be the least breaking way to me without having to have a flag that users have to flip on. Downside: if that metric changes we may have to break users again.

Edit: nevermind; I just saw the linked issue (#3590) so you had already noticed the same 😅

[maryliag]

What I was thinking is that ideally the metric would be replaced with the new one, so I was planning on doing that on a follow-up PR from this one. Then we can decide if is okay to have the breaking change before the 3.0 or wait for that to have the new PR merged.
Agree that if the metric change it would be a breaking change, but there isn't much we can do about that anyway.