Handle `http.(request|response).header.cookie` like other string array attributes

[Lms24]

The JS SDK would like to align sending http request headers from a string attribute to a string array attribute per header to align with the required attribute type in Sentry Conventions. SDK PR: getsentry/sentry-javascript#24231

While working on this, I noticed some issues with cookie HTTP headers (and potentially also Set-Cookie headers).

Following up on a Slack conversation about how Relay handles scrubbing of http.(request|response).header.cookie attributes, I tried sending cookie header attributes in various forms to Sentry to verify what would happen if the JS SDK changed how they're sent today.

Here are the attributes the SDK sent for each scenario:

// Scenario A: cookies combined into one attribute
"http.request.header.cookie": ["foo=bar", "language=en"],

// Scenario B (what the SDK currently does): One attribute per cookie as string
"http.request.header.cookie.sessionid": "s3cretsessionid",
"http.request.header.another-header-ii": "string-val",

// Scenario C: One attribute per cookie as array
"http.request.header.cookie.theme": ["dark"],
"http.request.header.cookie.csrf": ["s3cretvalue"],
"http.request.header.another-header": ["xyz", "abc"],

This is the resulting trace in Sentry

So from what I observed:

• Scenario A: The http.request.header.cookie holding an array of cookie values is dropped completely, regardless of the cookie names in there being sensitive (like csrf or not).
• Scenario B: Works as expected, unfortunately, it diverges from sentry-conventions how, http header attributes should be sent (as string[] and not as  string ).
• Scenario C:  works for non-sensitive cookie names, aber but when a sensitive cookie name is used (like csrf ), the entire attribute is dropped and not marked as [Filtered] like in scenario B.

Request: Can we adjust Relay that scenario A works? If not, can we fix scenario C? At the moment, the JS SDK sends string values (Scenario B). Technically, we can continue doing that but that also means we keep diverging from the expected attribute type in conventions. From an in-office convo with @Sebastian Zivota, I think generally, we should scrub arrays attributes element by element but it seems like we special-cased the http.request.header.cookie previously. Maybe, now that we actually support array attributes, we don't need to do that anymore?

I think the ideal outcome would be that the SDK sends Scenario A (fully in line with conventions) and we scrub this attribute element by element.

[linear-code]

RELAY-279