internal/telemetry: implement temporary telemetry fix for configurations

[zarirhamza]

What does this PR do?

Implements a new type of telemetry function IntegrationConfigChange that masquerades as an AppStart request due to limitations on the intake level. This will be overwritten once @eliottness fixes the telemetry client to include other request types.

Motivation

We want to be able to track configuration changes despite limitations on the backend. This way we can send events that we know for sure are not filtered out and appear on all data tracking services on the backend

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!

[datadog-datadog-prod-us1]

Datadog Report

Branch report: zarir/implement-temp-telemetry-integrations
Commit report: 9e4b604
Test service: dd-trace-go

✅ 0 Failed, 5208 Passed, 72 Skipped, 2m 27.61s Total Time

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-01-23 18:43:59

Comparing candidate commit 267d936 in PR branch zarir/implement-temp-telemetry-integrations with baseline commit 700f43e in branch main.

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

scenario:BenchmarkInjectW3C-24

• 🟥 execution_time [+112.889ns; +144.111ns] or [+2.809%; +3.585%]

scenario:BenchmarkPartialFlushing/Disabled-24

• 🟩 execution_time [-12.247ms; -9.478ms] or [-4.413%; -3.415%]

scenario:BenchmarkPartialFlushing/Enabled-24

• 🟩 execution_time [-10.975ms; -8.257ms] or [-3.906%; -2.939%]

scenario:BenchmarkStartRequestSpan-24

• 🟩 execution_time [-12.967ns; -11.693ns] or [-3.483%; -3.141%]

[eliottness]

Actually maybe wrapping the call of this new function in httptrace in a sync.Once could help a lot mitigate the lock contention customers would get as a result of this