fix(profiling): Fix accidentally correct Android profile chunk parsing

[0xadam-brown]

Overview

Fixes logic for handling Android profile chunks that pass through AndroidOrV2ProfileChunk::parse (viz., Android trace profiles and Android ANR profiles). Prior to this commit, the ::parse implementation worked only because it had been tailored to the quirks of existing Android trace + ANR profiles. But that special-casing will break once the updates to ANR billing under JAVA-548 are complete.

This commit anticipates JAVA-548 by:

1. routing Android trace profile chunks by their payload shape, and allowing all ANR profiles to (rightly) be parsed as V2ProfileChunk's; and

2. parsing + serializing Android trace chunks with a new 2.android-trace version so downstream consumers can distinguish them from sample v2 chunks.

Note: we now reject v1 and versionless Android trace profile chunks. Our Android SDK implementation suggests they were always unwanted; this commit makes that explicit. (But see the comment here.)

JAVA-634

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[0xadam-brown]

⚠️ Note that we previously mapped any chunks with the "android" platform to AndroidProfileChunk. Now we do so only if is_android_trace_profile is true.

My research here indicates the new (and narrower) approach works well with Sentry's own SDK implementations:

But what about non-Sentry implementations? Do we want to support anyone who might be relying on Relay's existing approach of parsing anything with an "android" platform as AndroidProfileChunk? We could easily do so by including a if (platform == android) => AndroidProfileChunk::parse(data) fallback after the (sample::Version::V2, _) check.

I've omitted the fallback because it requires extra explanation to understand what's going on + it'd leave a live code path "just in case", and I assumed we probably don't want to support speculative use cases. (I've added a callout in the CHANGELOG instead.)

Chime in if you think otherwise and I can easily include that fallback....

---

Note: all values that currently pass through AndroidOrV2ProfileChunk::parse are covered by the red box in the table above. (The "cocoa" platform is representative of all non-Android platforms.) W/r/t any previous Sentry SDK implementations, my LLM confirmed that this PR can handle all historical profile types that i) would currently be routed through AndroidOrV2ProfileChunk::parse and ii) should be mapped to AndroidProfileChunk.

[sentry-warden]

unbounded JSON deserialization depth in AndroidOrV2ProfileChunk::parse

Attacker-controlled profile chunk bytes are deserialized with serde_json without a caller-side recursion depth limit. The default max_profile_size (50 MiB) bounds payload bytes but not JSON nesting depth; a payload with millions of nested objects or arrays causes an uncatchable stack-overflow abort in serde_json's recursive visitor.

Evidence

• relay-server/src/processing/profile_chunks/process.rs:89 calls AndroidOrV2ProfileChunk::parse(&item.payload()) with attacker-controlled profile chunk bytes.
• relay-profiling/src/profile_chunk.rs:132: first deserialization into MinimalProfile uses serde_json::Deserializer::from_slice with no depth limit; the sampled_profile: Option<serde::de::IgnoredAny> field triggers recursive traversal of arbitrarily nested JSON.
• relay-profiling/src/profile_chunk.rs:171 and relay-profiling/src/profile_chunk.rs:176: the same data is re-parsed by AndroidProfileChunk::parse and V2ProfileChunk::parse, both also using unbounded serde_json::Deserializer::from_slice; unknown nested fields are skipped via deserialize_ignored_any, again recursing per nesting level.
• relay-config/src/config.rs:728 sets max_profile_size to ByteSize::mebibytes(50) by default. This byte cap is enforced before parsing (relay-server/src/utils/sizes.rs), but it bounds the wrong dimension: 50 MiB allows roughly 7 million nesting levels with compact nested objects ({"a":...}), far exceeding the default 8 MiB native stack.
• No recursion depth limit, custom deserializer guard, or serde_json depth configuration is visible anywhere in the three deserialization paths.

_{Identified by Warden · wrdn-dos-review · RZD-T7M}

[sentry-warden]

Android profile chunk parsing delegates to unbounded third-party binary parser

Untrusted profile chunk data routed through AndroidProfileChunk::parse reaches android_trace_log::parse with no caller-side element-count, depth, or internal-allocation bound on the decoded binary format.

Evidence

• expand_json_item in relay-server/src/processing/profile_chunks/process.rs:89 calls AndroidOrV2ProfileChunk::parse(&item.payload()) on envelope items of type ProfileChunk.
• AndroidOrV2ProfileChunk::parse at relay-profiling/src/profile_chunk.rs:171 routes to AndroidProfileChunk::parse(data) when is_android_trace_profile is true (including the newly added version == V2AndroidTrace condition from this PR).
• AndroidProfileChunk::parse at relay-profiling/src/android/chunk.rs:96 base64-decodes the sampled_profile field and calls android_trace_log::parse(&profile_bytes) at chunk.rs:100.
• No caller-side check limits the decoded byte length, declared element counts, recursion depth, or total allocations performed by the third-party binary parser before the call.
• Envelope-level max_profile_size() (default 50 MiB) caps the total JSON payload size but does not prevent the binary parser from allocating disproportionate memory based on format-declared counts within that bounded input.

_{Identified by Warden · wrdn-dos-review · ZWW-DCC}