WIP: contrib/google.golang.org/grpc: trace grpc encoding

[rarguelloF]

What does this PR do?

Motivation

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.
• 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: 2024-10-31 16:54:21

Comparing candidate commit 3081731 in PR branch rarguelloF/trace-grpc-encoding with baseline commit 3cb8ab2 in branch main.

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

scenario:BenchmarkTracerAddSpans-24

• 🟥 execution_time [+87.268ns; +137.932ns] or [+2.230%; +3.525%]

[darccio]

@rarguelloF Is this upgrade (and related) needed? If yes, we'll have to clearly state we support this integration from a specific version.

[rarguelloF]

Is this upgrade (and related) needed?

encoding.RegisterCodecV2 was not available on the previous version (in the one we were using, there was encoding.RegisterCodec). I am unsure what happens in someone uses the latest grpc, which registers the default codec using the V2 function, and we register ours using the V1.

we'll have to clearly state we support this integration from a specific version.

I think this is implicit from the go.mod right? since user's grpc version will automatically upgrade when they use this dd-trace-go version.

[darccio]

We could add a comment just to make sure we also know from which version is available. WDYT?

[darccio]

Is this order always stable? It looks like a potential flaky test.

[rarguelloF]

I think it should be, the sequence of the operations should be this. The existing tests assume the order of the server / client spans and don't seem to be flaky, but if it turns out to be flaky we can change this to find the spans by name.