ref(security): Stop accepting Expect-CT, HPKP, and Expect-Staple reports

[mrduncan]

HPKP, Expect-CT, and Expect-Staple are dead in all shipping browsers, so these report types can no longer be produced. Relay now rejects them at ingest: the security report classifier no longer recognizes them, and the dedicated expect-ct-report / expect-staple-report content types are refused at the endpoint.

This is the ~simplest change so that we stop accepting these reports and keep this PR manageable. The remaining cleanup should be straightforward as a follow up.

Planned removal: August 17th.

Refs getsentry/sentry#119638

[jjbayer]

Looks reasonable to me. We'll have to remove the sentry-side relay_integration tests in order for CI to pass.

[Dav1dde]

This is the ~simplest change so that we stop accepting these reports and keep this PR manageable. The remaining cleanup should be straightforward as a follow up.

To fully stop ingestion we'll also have to remove it from the EventType enum and ideally also the fields on the Event schema:

    /// HPKP (security) reports.
    #[metastructure(pii = "true", legacy_alias = "sentry.interfaces.Hpkp")]
    #[metastructure(omit_from_schema)] // we only document error events for now
    pub hpkp: Annotated<Hpkp>,

    /// ExpectCT (security) reports.
    #[metastructure(pii = "true", legacy_alias = "sentry.interfaces.ExpectCT")]
    #[metastructure(omit_from_schema)] // we only document error events for now
    pub expectct: Annotated<ExpectCt>,

    /// ExpectStaple (security) reports.
    #[metastructure(pii = "true", legacy_alias = "sentry.interfaces.ExpectStaple")]
    #[metastructure(omit_from_schema)] // we only document error events for now
    pub expectstaple: Annotated<ExpectStaple>,

Can be done in a follow-up, but maybe easier to do it in one sweep. Without making these changes, outdated customer hosted Relays and custom clients can still send these reports.

[sentry-warden]

Security report JSON parsed without depth limit via unbounded serde_json deserialization

Attacker-controlled payload bytes reach serde_json::from_slice through an untagged enum (CspVariant) with no caller-side nesting or depth guard, allowing a deeply-nested JSON payload to overflow the stack during parsing. The existing ~1 MiB byte-size cap does not prevent the attack because a 1 MiB payload of nested objects or arrays can contain ~100 k–500 k nesting levels.

Evidence

• item.payload() in relay-server/src/processing/errors/errors/raw_security.rs receives untrusted request bytes already bounded to max_event_size() (~1 MiB by default) via DefaultBodyLimit and check_envelope_size_limits.
• Those bytes are passed to Csp::apply_to_event(data, &mut event), which calls serde_json::from_slice::<CspVariant>(data) at relay-event-schema/src/protocol/security_report.rs:585.
• CspVariant is an untagged enum (#[serde(untagged)]), so serde buffers the entire JSON value into a recursive Content tree before matching variants.
• A 1 MiB payload of nested objects or arrays can reach ~100 k–500 k nesting levels, enough to overflow the native stack during recursive deserialization, causing an uncatchable process-wide abort.
• No caller-side JSON depth limit is applied; by contrast, MessagePack deserialization in the same codebase (relay-server/src/utils/rmp.rs) caps nesting at MAX_DEPTH to protect against the same class of attack.

_{Identified by Warden · wrdn-dos-review · FJM-GJW}