[APMSVLS-497][APMSVLS-498] test: add fake-intake for APM payload-level tests

[lucaspimentel]

Overview

Adds an in-process fake Datadog intake for bottlecap so APM flush paths can be asserted at the payload-field level, not just "a request was made".

Stacked on top of #1210 (the StatsFlusher::new URL-parameter refactor). This PR targets lpimentel/stats-flusher-url-param and should be merged after #1210 lands.

Before this PR, no APM payload flushed by bottlecap was covered by integration tests. The existing httpmock-based tests for logs and metrics only check body_contains(<substring>) on raw bytes, so they can't catch regressions in stats bucket structure, span attribution, peer tags, or any other decoded field.

This PR implements phase 1 of the fake-intake work (APMSVLS-496), covering both sub-tickets:

• APMSVLS-497 — fake-intake scaffold + StatsPayload msgpack decode + first stats integration test.
• APMSVLS-498 — AgentPayload protobuf decode + first trace-payload integration test.

Changes:

• bottlecap/tests/common/fake_intake.rs — axum server on a random local port accepting /api/v0.2/stats (msgpack + gzip) and /api/v0.2/traces (protobuf with zstd/gzip/identity decompression). Decodes each body on arrival and stores pb::StatsPayload / pb::AgentPayload for tests to query. Decompression failures return HTTP 400; unknown Content-Encoding values are warned.
• bottlecap/tests/apm_integration_test.rs — two new integration tests:
  • stats_payload_roundtrip_through_fake_intake: drives StatsFlusher::send and asserts on hit counts, span kind, peer tags, and HTTP metadata.
  • trace_payload_roundtrip_through_fake_intake: drives TraceFlusher::flush through the real aggregator and asserts on trace/span IDs and service metadata.
• bottlecap/Cargo.toml — adds rmp-serde and flate2 as dev-dependencies.

Phase 2 will extract this module into a shared crate consumed by both bottlecap and SCL; the module is deliberately bottlecap-type-free to make that extraction mechanical.

Testing

• cargo test --test apm_integration_test — both new tests pass locally and on Linux CI
• cargo test — full bottlecap test suite passes locally (522 unit tests + integration/doc tests), no regressions
• RUSTFLAGS="-D warnings" cargo clippy --workspace --all-targets --features default — clean locally and on Linux CI
• cargo fmt --all -- --check — clean locally

"Finally, a way to ask our StatsPayloads how they're really feeling, and not just whether they showed up to work." — Claude

[Copilot]

Pull request overview

This PR introduces an in-process “fake Datadog intake” test harness for Bottlecap APM payload-level integration testing, enabling assertions on decoded stats/traces payload fields rather than only verifying that an HTTP request occurred.

Changes:

• Add FakeIntake axum server that accepts /api/v0.2/stats and /api/v0.2/traces, decodes bodies, and stores pb::StatsPayload / pb::AgentPayload for tests.
• Add new APM integration tests that exercise the stats and traces flush paths and assert on decoded payload fields.
• Make StatsFlusher::new accept an explicit stats intake URL so tests can redirect it to the fake intake; update the production call site accordingly.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
bottlecap/tests/common/mod.rs	Adds a shared tests/common module exposing fake_intake.
bottlecap/tests/common/fake_intake.rs	Implements the in-process fake intake server with decoding and captured payload storage.
bottlecap/tests/apm_integration_test.rs	Adds payload-level integration tests for stats and traces flush paths.
bottlecap/src/traces/stats_flusher.rs	Accepts stats_url in the constructor and logs the actual endpoint used.
bottlecap/src/bin/bottlecap/main.rs	Passes trace_stats_url(&config.site) into StatsFlusher::new.
bottlecap/Cargo.toml	Adds dev-dependencies for msgpack and gzip decoding used by the fake intake.
bottlecap/Cargo.lock	Updates lockfile for the new dev-dependencies.

[duncanista]

Seems like the stats URL change is different to what this PR claims, do we really need them together?

[lucaspimentel]

@duncanista

Seems like the stats URL change is different to what this PR claims, do we really need them together?

I split that small refactor out into #1210 and stacked this PR on that one.