fix(integrations): Treat specific CustomEvents as promise rejections

[lobsterkatie]

As explained here, we've started seeing a rash of events with a specific structure that are spamming certain customers. TL;DR, this handles those events more gracefully so they can be properly filtered.

Background

Both PromiseRejectionEvent and CustomEvent implement the Event interface, but they each add at least one property not included in Event's spec. In the case of PromiseRejectionEvent, it adds promise (the promise that rejected) and reason (the argument which would have been passed to a .catch clause in the promise chain, had there been one; in the case of an error being thrown inside the promise, reason is that error). For CustomEvent, it's detail.

The events we're seeing have all the data of a PromiseRejectionEvent (including type: unhandledrejection), but they're not PromiseRejectionEvents - they're CustomEvents, with the promise and reason properties from the former stored in an object in the detail property of the latter. And because they're structured differently, currently the SDK doesn't handle these events gracefully, or rather: it handles them as gracefully as it handles any other CustomEvent- pulls as much data as it can off of it and serializes that data in extra, but doesn't recognize it as something it can do anything more with, even if event.detail.reason is in fact a full-fledged Error.

The Current Problem

This has come up recently because multiple customers are getting spammed by events like this, all with the same error nested inside them: Extension context invalidated. This turns out to be an error that Chrome throws when an extension stops being able to communicate with the script it's injected into a given page. If one or the other end of that communication channel continues to ping its (now-missing) interlocutor, and doesn't catch the errors (and then promise rejections) which result, a large number of events can pile up, even from a single end user. (This tracks with what we're seeing in customers' accounts, where in some cases tens of thousands of events are being generated by just a few dozen users.)

Unless you're the extension developer, these events are just third-party noise that eat your quota, and while they can be blocked manually using beforeSend, this takes effort (and probably writing into support) and feels like a hack when we have a server-side filter explicitly designed to handle such problems. That filter can't currently act on these events because of their weird structure, but...

The Solution

By now it should be clear where this is headed. If we can dig the Error out of the CustomEvent, we can then filter it like we would any other browser extension error. This does that digging, both in the GlobalHandlers integration and the pared down version present in the loader. (It also fixes a random typo I found in the dedupe integration while researching this.)

Tests can be found in #2431.

Fixes #2380.

[getsentry-bot]

	Messages
📖	✅ TSLint passed
📖	@sentry/browser bundle gzip'ed minified size: (ES5: 16.7314 kB) (ES6: 15.7412 kB)

Generated by 🚫 dangerJS against 2988340

[kamilogorek]

These pesky browsers... great fix, thanks!