RFC: Make it easier to test Sentry config

[bryophyta]

There are at least four conditions which are necessary for a client-side error to be received by Sentry:

1. The page falls into the sample (1/100) which loads Sentry.
2. An error occurs.
3. The enableSentryRecording switch is set to true for the current stage.
4. The Sentry SDK is correctly configured (no bugs; correct tokens provided etc.)

This makes it difficult to test (4) when changes are made to the config (e.g. upgrading the SDK version).

It would be useful if we had a page where we knew a client-side error would be raised, and on which we bypass the sampling stage (i.e. always load Sentry on that page). Given this, we could just toggle the enableSentryRecording switch for CODE when we needed to test (4).

An alternative would be to disable sampling for CODE pages (example implementation here). You don't need to click around for too long before an error will arise so if we bypass the sampling then it's not too cumbersome to test. This would, however, mean that we'd need to be careful to turn the enableSentryRecording switch off again after testing, or else we'd end up logging a lot of errors whenever people use CODE.

There are some other options (e.g. add a new query parameter, or a new switch, to control this behaviour) but the two outlined above seem like the most straightforward.

Comments and suggestions very welcome!

Update

@arelra's refactor of the Sentry loading script (#6829) suggests a good pattern for bypassing the random centile sampling.

[rhiannareechaye]

Since we have over 130 health tickets in our health board, we have closed a number of tickets. This ticket has not been prioritised, but we don't want to close it. If we get through all the tickets under our 'Small(ish), high impact, tickets' by the end of the Q, we will revisit this ticket. For now we unfortunately have to leave it in the limbo that is 'Triage revisit'