[otelmongo] bump semconv to 1.26.0

[prestonvasquez]

Problem Statement

otelmongo is currently using semconv/v1.17.0, suggest updating to semconv/v1.26.0.

Proposed Solution

key/value pair changes migrating from 1.17.0 to 1.26.0 include:

Old Func	New Func	Old Key	New Key	Notes
DBOperation	DBOperationName	db.operation	db.operation.name
DBName	DBNamespace	db.name	db.namespace
NetPeerName	NetworkPeerAddress	net.peer.name	network.peer.address	Currently the hostname is used for the peer name. Documentation suggest using the server address.
NetPeerPort	NetworkPeerPort	net.peer.port	network.peer.port
NetTransportTCP	NetworkingTransportTCP	net.transport	network.transport	Network transport no longer includes the ip_ portion defined on the deprecated net.trasnport. Instead, this value is either tcp or udp.
DBStatement	DBQueryText	db.statement	db.query.text	There is no deprecated analogue to `db.statement` according to the documentation. Db.query.text seemed like a natural fit.

Alternatives

Since these fields are deprecated, there is no alternative other than leaving the semconv version static.

Prior Art

NA

Additional Context

It's worth noting that this is a breaking change if telemetry key/values are considered stable.

[prestonvasquez]

A major version release of otelmongo should be planned before bumping to 1.26.0: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#semantic-conventions-stability

OTEL_SEMCONV_STABILITY_OPT_IN is not intended for already stable releases, see here.

[pellared]

@prestonvasquez, why was it closed?

[prestonvasquez]

@pellared I wasn't aware we still wanted to do this. Should I re-open the PR?

[pellared]

A major version release of otelmongo should be planned before bumping to 1.26.0: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#semantic-conventions-stability

I do not follow why we want to create a major version of otelmongo prior bumping the semantic conventions.

I think it may make sense to coordinate the strategy of bumping the DB semconvs to the latest version at least with @XSAM who maintains https://github.com/XSAM/otelsql.

[prestonvasquez]

@pellared The rationale can be found here: open-telemetry/semantic-conventions#1502 (comment)

OTEL_SEMCONV_STABILITY_OPT_IN [is] for the initial unstable to stable migration, and not subsequent major version bumps from stable -> (breaking) stable

Once we bump to 1.x, OTEL_SEMCONV_STABILITY_OPT_IN is no longer usable.

[pellared]

@prestonvasquez, there are two things: stability of semantic conventions and stability of instrumentation library.

Once we bump to 1.x, OTEL_SEMCONV_STABILITY_OPT_IN is no longer usable.

We can still have unstable instrumentation library (v0.x) that produces stable telemetry (compliant with semantic conventions).

The OTEL_SEMCONV_STABILITY_OPT_IN is introduced to give a "user-friendly" migration path for users of both stable and unstable instrumentation libraries to migrate from legacy semantic conventions to new semantic conventions.

You can look at HTTP Instrumentation project how we want to help otelhttp users migrating from HTTP legacy semantic conventions to stable HTTP semantic conventions: Go: HTTP Semconv Migration

Additional reference: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/telemetry-stability.md

[prestonvasquez]

@pellared

The OTEL_SEMCONV_STABILITY_OPT_IN is introduced to give a "user-friendly" migration path for users of both stable and unstable instrumentation libraries to migrate from legacy semantic conventions to new semantic conventions.

OTEL_SEMCONV_STABILITY_OPT_IN is not intended to be used with stable instrumentation libraries. It should be used when we make a breaking change in the unstable library with the guarantee that this change will be main path in the stable upgrade.

What do you propose we do?