Kuma: Client side Sentry for React front-end

[tobinmori]

Summary
We should be getting client-side errors, sent to Sentry, if they happen in the wild.

Audience
Core developers.

Rationale
We currently rely on users to report bugs in the client-side code by filing tickets.

Workaround
Leaving as is.

Proposal
Add the Sentry SDK into the React bundle and make sure we have the Sentry PUBLIC DSN configured.

Additional context
It would be nice to have different DSN for stage vs prod. Can this be done with our Jenkins stuff @escattone ?

Also, there might be a might flood of messages from various weird browsers with with weird browser extensions that cause all sorts of errors that have nothing to do with our code.
For that, it be a good idea to point to Sentry project (under the mdn team) just for front-end so we don't get too flooded by all the email notifications.

[peterbe]

Note-to-self; here are the docs: https://docs.sentry.io/platforms/javascript/react/
But for this to work we need the environment variable to be available which is this issue: https://github.com/mdn/infra/issues/308

[escattone]

@limed @peterbe @tobinmori I just realized that with this approach, i.e. baking the public DSN into the JS bundle that gets built when the mdnwebdocs/kuma Docker image is built (see https://github.com/mozilla/kuma/blob/74115fbe5aa823667d3f581e45b6e78fae15243c/docker/images/kuma/Dockerfile#L14), we'd need separate Docker images for stage and prod. At the very least, that entails changes to our Kuma Jenkins code (generating different image names like mdnwebdocs/kuma-stage:<commit-hash> and mdnwebdocs/kuma-prod:<commit-hash> when building) and our Kuma-based K8s deployments (using those new image names based on the target environment, stage or prod).

[tobinmori]

closing this because:

• makes deploys more difficult
• would increase bundle size
• GA tweaks seem to be providing good enuff err msgs