chore: identify candidate dependencies for removal/replacement/absorption

[darccio]

What does this PR do?

Identifies all the dependencies that might be removed, replaced by an already present similar dependency or absorbed into dd-trace-go.

Motivation

Reduce the number of dependencies to reinforce our supply chain.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running ./scripts/lint.sh locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild.

Unsure? Have a question? Request a review!

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-11-28 09:54:16

Comparing candidate commit 183054e in PR branch dario.castane/apmlp-494/exploration with baseline commit 8f03e3d in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 15 metrics, 0 unstable metrics.

[kakkoyun]

Thanks for identifying all these. Extremely helpful.

My question is do we need to actually merge this PR?
We can keep this open as draft, or add another markdown document with check list until we tackle all.

I'm just not sure if it is a good idea to have these in the code comments.

[darccio]

@kakkoyun Agreed. There is no real need to merge them, although it's nice to have this in an easy format to review. I can set it to draft and create PRs linking to this one.

[eliottness]

wondering if they are function we use from golang.com/x/<...> that have made it into the standard library in the meantime

[darccio]

wondering if they are function we use from golang.com/x/<...> that have made it into the standard library in the meantime

I can check them. I didn't prioritize them because, even if they are /x/, they don't usually break in unexpected ways.

[darccio]

@kakkoyun Is this dependency needed in the root module?

[kakkoyun]

It is only needed for the CI check and it's under a build flag. We can experiment how we can remove it from the root module. It's definitely not needed for the runtime, it's a build time dependency.

[darccio]

I checked the golang.org/x/* dependencies and I didn't find anything but the xerrors dependency. I think it can be removed, but I also feel that the potential breakage out-weights the benefit of removing it.