util/tracing: remove semconv dependency

[thaJeztah]

Replace semconv imports with local constants for semconv keys.

These attributes are marked Stable in the OpenTelemetry Semantic Conventions and are not expected to change across semver releases:

• https://opentelemetry.io/docs/specs/semconv/
• https://opentelemetry.io/docs/specs/otel/versioning-and-stability/#semantic-conventions-stability

This avoids pulling in versioned semconv packages solely for stable attribute keys and prevents duplicate semconv versions in the module graph.

[thaJeztah]

From what I could find, it's OK to keep this empty (the GoDoc linked above describes "must be non-empty" but that applies to semconv itself); alternatively we can pin this to a version ("https://opentelemetry.io/schemas/1.37.0" for example), but looks like there's no real benefit?

[jsternberg]

I'd prefer that we keep the schema url to be something. This is just mostly so just in case they do change something we're advertising which semconv version we're using.

[thaJeztah]

Yeah, makes sense; won't do harm.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tonistiigi]

What's the benefit of duplicating these, considering the semconv pkg is vendored anyway?

[jsternberg]

I'm ok with this. We're unlikely to change it and if it means that other projects don't have to vendor useless code or that we vendor less I'm good with it.

[thaJeztah]

What's the benefit of duplicating these, considering the semconv pkg is vendored anyway?

My motivation was that I started to see us accumulate a trip down memory lane for OTEL "SemConv" versions; it's not a separate module (it's a "versioned" package), so every import of any semconv/vx.y.z will add another copy of that version to vendor/, each 10k+ LOC. While that won't really have an impact on the binary size (we only consume a couple of consts, and there's probably not a lot more in that package), it still means more code-churn.

While previously we had to make sure we'd align because these properties weren't stable yet; they're now stable, so we're effectively importing 10k+ code for 5 strings that will never change.

With this PR, our own imports won't change, and updating OTEL+OTEL/contrib versions (when done at the same time) should more likely see the semconv files to be a lateral move / rename of the files (with only differences between old and new version as diff), instead of "add another copy of these files"). I already did similar PRs in Moby and Containerd, so with a bit of luck the only "versioned" imports will now be from OTEL itself, which will just be updated when we update OTEL dependencies.

For reference; size is not the issue; looking at dockerd (76 kB + 1.1 kB + 419 B) and containerd;

[jsternberg]

While previously we had to make sure we'd align because these properties weren't stable yet; they're now stable, so we're effectively importing 10k+ code for 5 strings that will never change.

Just for a bit of context on this, the versioned semver packages will never change even if they were unstable or beta. That's what the schema url is meant for is to allow the names to change. At the same time, these specific properties, while they theoretically could change, are unlikely to ever change just due to how ingrained they are and how many people it would inadvertently break.