Remove withScope Sentry calls in favor of using tags directly (1)

What does this MR do and why?

Implements #427607 (closed)

This change simplifies some Sentry calls that use tags to label errors by using withScope. Instead, we simply use the tags: entry in the scope that we can pass using captureException.

Screenshots or screen recordings

I mocked an error in one of the components I am actively working on at http://gdk.test:3000/admin/runners

$ git diff
diff --git a/app/assets/javascripts/ci/runner/components/runner_list.vue b/app/assets/javascripts/ci/runner/components/runner_list.vue
index ec04701db2c0..6b37c393b528 100644
--- a/app/assets/javascripts/ci/runner/components/runner_list.vue
+++ b/app/assets/javascripts/ci/runner/components/runner_list.vue
@@ -88,6 +88,9 @@ export default {
       return fields;
     },
   },
+  mounted() {
+    throw new Error('mock error');
+  },
   methods: {
     canDelete(runner) {
       return runner.userPermissions?.deleteRunner;

In particular, I wanted to verify the tags where preserved when using captureException with tags directly, so I checked the payload we send to Sentry, to confirm the tags are still there:

Both master and this branch behave in the same way 👍 so our Sentry reporting does not change.

How to set up and validate locally

1. Enable 2 feature flags:
   • Feature.enable(:enable_new_sentry_clientside_integration)
   • Feature.enable(:configure_sentry_in_application_settings).
2. Testing on GDK requires disabling CSP on your browser (I temporarily used https://chrome.google.com/webstore/detail/disable-content-security/ieelmcmcagommplceebfedjlakkhpden, caution, don't keep this extension installed)
3. Enable Sentry at Admin -> Metrics and profiling http://gdk.test:3000/admin/application_settings/metrics_and_profiling#js-sentry-settings, with the setting you see here.
   • You don't have to use a real Clientside DSN here, https://XXX@new-sentry.gitlab.net/4 will work.
4. See the outgoing requests from your browser console, exceptions we report should have the same values as before.

I don't think we need to cover each case modified here, and I've verified this works locally when sending tags.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #427607 (closed)