fix(browser): Ensure propagated parentSpanId stays consistent during trace in TwP mode

[Lms24]

This PR adjusts how we set treat the parentSpanId when propagating it in an SDK configured for tracing without performance. Previously, we didn't set the propagationSpanId on the propagationContext (which is supposed to be serialized to the parent span id in the sentry-trace (and traceparent) header, if no active span is present.
This had the consequence that every time getTraceData() was called, we'd return a new, random (non-existing) parent span id. Meaning, that if we generate both, sentry-trace and traceparent headers via getTraceData() they'd end up with different parent span ids in the respective hedaers.

With this change, we now set a propagationSpanId on the PC, which has two effects:

1. consistent parent span id in sentry-trace and traceparent headers for the same outgoing request
2. consistent parent span ids in all outgoing requests until the next navigation when the PC is recycled

So this prolongs the time span in which we propagate the same parent span id. Since this span doesn't exist, I think this is fine. Though happy to drop this if reviewers have concerns. The main benefit with this change is 1 in combination with us generating traceparent from raw data rather than parsing the already generated sentry-trace header and converting its parts into traceparent.

(TwP was a mistake)

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.16 kB	-	-
@sentry/browser - with treeshaking flags	22.73 kB	-	-
@sentry/browser (incl. Tracing)	40.15 kB	+0.06%	+23 B 🔺
@sentry/browser (incl. Tracing, Replay)	78.49 kB	+0.04%	+27 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	68.27 kB	+0.04%	+26 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	83.17 kB	+0.03%	+23 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	95.39 kB	+0.03%	+27 B 🔺
@sentry/browser (incl. Feedback)	40.89 kB	-	-
@sentry/browser (incl. sendFeedback)	28.81 kB	-	-
@sentry/browser (incl. FeedbackAsync)	33.75 kB	-	-
@sentry/react	25.88 kB	-	-
@sentry/react (incl. Tracing)	42.12 kB	+0.06%	+23 B 🔺
@sentry/vue	28.64 kB	-	-
@sentry/vue (incl. Tracing)	41.95 kB	+0.06%	+21 B 🔺
@sentry/svelte	24.18 kB	-	-
CDN Bundle	25.74 kB	+0.02%	+3 B 🔺
CDN Bundle (incl. Tracing)	40.03 kB	+0.11%	+42 B 🔺
CDN Bundle (incl. Tracing, Replay)	76.31 kB	+0.06%	+42 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	81.78 kB	+0.06%	+47 B 🔺
CDN Bundle - uncompressed	75.29 kB	+0.18%	+129 B 🔺
CDN Bundle (incl. Tracing) - uncompressed	118.52 kB	+0.22%	+256 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed	233.61 kB	+0.11%	+256 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	246.37 kB	+0.11%	+256 B 🔺
@sentry/nextjs (client)	44.14 kB	+0.05%	+19 B 🔺
@sentry/sveltekit (client)	40.59 kB	+0.05%	+20 B 🔺
@sentry/node-core	49.67 kB	-0.04%	-16 B 🔽
@sentry/node	150.66 kB	-0.01%	-8 B 🔽
@sentry/node - without tracing	92.25 kB	-0.02%	-13 B 🔽
@sentry/aws-serverless	105.55 kB	-0.02%	-12 B 🔽

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,825	-	9,048	-2%
GET With Sentry	1,311	15%	1,254	+5%
GET With Sentry (error only)	5,984	68%	5,872	+2%
POST Baseline	1,203	-	1,179	+2%
POST With Sentry	496	41%	476	+4%
POST With Sentry (error only)	1,066	89%	1,024	+4%
MYSQL Baseline	3,274	-	3,266	+0%
MYSQL With Sentry	431	13%	387	+11%
MYSQL With Sentry (error only)	2,652	81%	2,684	-1%

View base workflow run

[Lms24]

This test confused me a bit, so I just added some comments. No change for consistent trace sampling!

[s1gr1d]

looks good! also thanks for refactoring the helper methods