Improve error throwing behaviour in browser integration test

[Lms24]

Problem Statement

Currently, it's quite annoying to just throw an error in a browser integration test and to check for the resulting payload. The intuitive way would be to just top-level call throw new Error() in subject.js. However, the resulting error gets thrown as a "Script Error" because it's thrown synchronously when the subject bundle JS is evaluated by the browser. This error is filtered by the SDK by default for good reason.

Solution Brainstorm

Ideally, we can work around this in one way or another so that we can have a simple way of throwing errors in a test that actually make it through the SDK. I have a couple of ideas but we'd need to check what the best approach is. Also I'm definitely open to other ideas.

1. wrap subject.js code in a setTimeout call. This will cause the initial bundle evaluation to succeed and potential errors should be thrown as intended by testers.
2. let the test framework accept another file (e.g. async-subject.js) that does what's suggested in 1. subject.js would stay sync as previously.
3. we could just create a test utility (e.g. triggerError(err: unkown)) that calls page.evaluate. This should work 🤔 but admittedly I didn't test it yet

[onurtemizkan]

@Lms24, I think the 3rd one would be the most intuitive if it works for every case we test (and the cases we don't properly test due to the current limitations). I can give it a shot if that makes sense?

[Lms24]

Yup, sounds good to me!

[AbhiPrasad]

@onurtemizkan feel free to convert the tests added from #11666 after we merge that in to test everything out!