fix(core): Prevent exception recapturing

[lobsterkatie]

When we instrument code to catch exceptions, once we've recorded the error we rethrow it, so that whatever would have happened without us still happens. Sometimes, that means that we'll see the same exception (as in, literally the same instance of Error) again, because it will hit some other code we've instrumented.

The clearest example of this is us catching an exception in, say, an event handler, recording it, rethrowing it, and it then hitting our wrapped global onerror. We already handle that particular case, but the nextjs SDK has introduced other places where this happens, which our current solution doesn't handle.

(Specifically, because we instrument the code in different (but overlapping) ways to compensate for differences between Vercel and non-Vercel environments, in non-Vercel environments we can end up seeing errors get caught twice.)

This prevents us from capturing the same error twice by flagging the object as seen and bailing if we encounter an error with the flag set. Since people do all sorts of crazy things, and throw primitives (especially strings), it also accounts for that case, by wrapping any primitive it encounters with its corresponding wrapper class. Finally, it takes advantage of this change in @sentry/nextjs's withSentry wrapper, to prevent the cases mentioned above.

(Note: This is a different case than the Dedupe integration is meant to handle, which is two copies of the same error in a row. In this case, though the thing which gets thrown is the same the first and second times we see it, the stacktrace to get to it being captured is different, since different instrumentation is involved each time.)

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	22.47 KB (+0.4% 🔺)
@sentry/browser - Webpack	23.35 KB (+0.39% 🔺)
@sentry/react - Webpack	23.38 KB (+0.38% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	29.91 KB (+0.32% 🔺)

[iker-barriocanal]

Pushing back because of tests.

[iker-barriocanal]

A switch where the condition is always the same value doesn't seem very reasonable to me. Why not if..elif..else?

[lobsterkatie]

This is just a different (and in some cases, cleaner) way to write a long series of if-elses. Here's a blog post about it: https://seanbarry.dev/posts/switch-true-pattern.

[lobsterkatie]

Thanks for the detailed review! I cleaned up the tests and added comments where it seems like things might have been unclear.