ref(sveltekit): Remove custom client fetch instrumentation and use default instrumentation

[Lms24]

This PR removes our custom SvelteKit client fetch instrumentation which we created when we initially worked on the SDK. Back then I didn't think that it's possible to use our default fetch instrumentation from BrowserTracing, due to timing issues where Kit would store away window.fetch (and use the stored version in load functions) before our SDK was initialized.

After receiving some hints how it might be possible, we now have a way to instrument fetch everywhere on the client (including the one in load) functions.

This works in two parts:

1. During the initial page load request, our server-side handle wrapper injects a script into the returned HTML that wraps window.fetch and adds a proxy handler (window._sentryFetchProxy) that at this time just forwards the fetch call to the original fetch.

After this script is evaluated by the browser, at some point, SvelteKit loads its initial client-side bundle that stores away window.fetch. Kit also patches window.fetch itself at this time.

Sometime later, the code from the hooks.client.js file is evaluated in the browser, including our Sentry.init call:

2. During Sentry.init we now swap window.fetch with window._sentryFetchProxy which will make our BrowserTracing integration patch our proxy with our default fetch instrumentation. After the init, we swap the two fetches back and we're done.

While this seems a little hacky and confusing at first, I believe this is actually quite a nice way of making things work and it comes with a number of advantages:

• We don't interfere with SvelteKit's caching of load function data (Svelte Kit fetch requests are repeated again during client hydration #8174)
  • We can remove the previously brittle vendored cache lookup code as our instrumentation now only adds headers to the request long after the lookup happened.
• We can use our proven BrowserTracing fetch instrumentation just as SDK users would expect and no longer need to duplicate logic just for SvelteKit
• We get rid of 700+ loc and reduce the client SDK's bundle size

(I worked on this while investigating #8610 as I initially believed that the issue was caused by a cache lookup bug in our instrumentation. That didn't turn out to be the cause but now we fixed two things 🎉 )

h/t @myieye for sharing their way of patching fetch

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	75.12 KB (+0.36% 🔺)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	31.14 KB (+0.09% 🔺)
@sentry/browser - Webpack (gzipped)	21.82 KB (+0.03% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	69.72 KB (+0.27% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	28.18 KB (+0.1% 🔺)
@sentry/browser - ES6 CDN Bundle (gzipped)	20.18 KB (+0.05% 🔺)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	219.89 KB (+0.38% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	84.78 KB (+0.13% 🔺)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	59.86 KB (+0.04% 🔺)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.04 KB (+0.08% 🔺)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	65.3 KB (+0.39% 🔺)
@sentry/react - Webpack (gzipped)	21.85 KB (+0.03% 🔺)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	92.94 KB (+0.31% 🔺)
@sentry/nextjs Client - Webpack (gzipped)	50.66 KB (+0.11% 🔺)

[AbhiPrasad]

Very clever approach!

[lforst]

[AlexRMU]

But what to do with CSP now?
Allow unsafe-inline?

[Lms24]

Tracking in #8925