contrib/net/http: support for path params from go 1.22 proposal

[eliottness]

What does this PR do?

This PR add support for importing path params into dd-trace-go/contrib/internal/httptrace data pipeline as multiple other contribs already do.

In details I did:

• Import the code that parses path patterns from net/http into dd-trace-go
• Setup a cache for the results of this operation
• Once the names have been extracted, loop over them and run (*http.Request).PathValue(name) and build a map[string]string with it

Motivation

• Better coverage for ASM WAF.
• Enabling a big bunch for tests in the system-tests that work with path params

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.
• For internal contributors, a matching PR should be created to the v2-dev branch and reviewed by @DataDog/apm-go.

Unsure? Have a question? Request a review!

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-01-14 17:24:34

Comparing candidate commit 697c5c0 in PR branch eliottness/net-http-path-params with baseline commit 471d723 in branch main.

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

scenario:BenchmarkHttpServeTrace-24

• 🟥 execution_time [+345.543ns; +470.657ns] or [+2.188%; +2.981%]

[rarguelloF]

LGTM! just left a small nit to improve readability 🙇

[rarguelloF]

nit: I had to dig into the implementation and tests to understand what this function returns (since the type []string doesn't give much information). I think it would be nice if this was added to the doc string for future readers to quickly understand what this function does.

Adding something at the end like:

Given a pattern like "GET /foo/{bar}/{baz}", it returns []string{"bar", "baz"}

Also having 2 functions getPatternNames and patternNames with almost the same function signature doesn't help much (the difference is the first one uses the cache first). WDYT about renaming this one to parsePattern or parsePatternNames? (ideally I think it should be parsePattern, because if we want to parse other stuff from it in the future we would likely want to do it only once).

[eliottness]

Applied all your comments (I believe) 👍