fix(replay): Fix xhr start timestamps

[mydea]

We've been using the wrong startTimestamp for the core xhr instrumentation. Outside of replay, this wasn't noticed because we are not actually using the anywhere 😬 But in replay, it lead to all xhr breadrcumbs showing an incorrect duration of 0.

Note that this is maybe not 100% correct, as in theory you could call xhr.send() later, which is probably the most correct start timestamp. But this would require us to keep the start time somewhere on the xhr object, which is a bit trickier than this solution. So I think it is fine to do this based on xhr.open() (and definitely more correct than it was before).

fixes getsentry/sentry#52790

[Lms24]

and definitely more correct than it was before

Agreed!

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	82.52 KB (+0.02% 🔺)
@sentry/browser (incl. Tracing, Replay) - Webpack with treeshaking flags (gzipped)	71.66 KB (+0.02% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	30.65 KB (+0.04% 🔺)
@sentry/browser - Webpack (gzipped)	21.25 KB (+0.05% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	73.03 KB (+0.02% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	28.7 KB (+0.05% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped)	21.09 KB (+0.06% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	233.78 KB (+0.01% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	87.1 KB (+0.01% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	62.73 KB (+0.01% 🔺)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.46 KB (+0.03% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	82.98 KB (+0.02% 🔺)
@sentry/react - Webpack (gzipped)	21.29 KB (+0.06% 🔺)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	99.39 KB (+0.01% 🔺)
@sentry/nextjs Client - Webpack (gzipped)	47.55 KB (+0.02% 🔺)

[damacisaac]

appreciate the fix - nice work!