fix(angular): Filter out TryCatch integration by default

[Lms24]

As explained in #5417 (comment), the TryCatch default integration interferes with the SentryErrorHander error handler of the Angular(-Ivy) SDKs by catching certain errors too early, before the Angular SDK-specific error handler can catch them. This caused missing data on the event in some or duplicated errors in other cases.

This PR filters out the TryCatch by default, as long as users didn't set defaultIntegrations in their SDK init. Therefore, it makes the previously provided workaround obsolete.

The fix isn't ideal for two reasons but IMO we should nevertheless do this now to fix a long lasting problem and clean things up in v8:

• If users did not set up SentryErrorHandler as documented, certain errors might not be caught anymore. However, I don't think we should degrade the Sentry experience for everyone who set up the SDK correctly to account for this edge case.
• We cannot remove the TryCatch integration from the exported defaultIntegrations array of the SDK as this would be a breaking change. This also means that the integration will be bundled and only filtered at runtime for now. I've added the removal of the integration to our v8 deprecation/removals list (JS SDK v8 Deprecations List #5194).

closes #2744
ref #5417

[Lms24]

We discussed another approach to this, namely deactivating the TryCatch integration when the error handler is initialized. The advantage of this approach would be that incomplete SDK setups would not be impacted by the fix and errors would still be caught by the TryCatch integration for in this case. However, after evaluating two possible implementations, I believe this isn't worth the effort:

• Angular-SDK-specific TryCatch integration
  • Extending TryCatch in the Angular SDK doesn't work because we already patch the timer functions in TryCatch during setupOnce. At this point, the Angular SDK cannot yet deactivate the integration because the error handler isn't yet initialized. So the only option would be to completely duplicate the TryCatch integration with a disable logic which IMO is unnecessary overhead and an increased maintenance burden for the edge case we want to account for.
• Changing the Browser SDK's TryCatch integration
  • Adding a disabling method to the original TryCatch integration unnecessarily increases bundle size as well as complexity for all other Browser-based SDKs, which I'd argue doesn't justify the minimal value this change would provide.

If we ever encounter a TryCatch problem like the one in the Angular SDK's case, we can/should revisit this and think about option two but for now I'd argue we move forward with filtering out TryCatch as proposed in this PR.

[AbhiPrasad]

I'd rather we take the approach to add a custom TryCatch specific to Angular, we can do this easily by refactoring the original TryCatch integration to add some additional protected methods that can be overriden.

Unfortunately this might be breaking because of people relying on the TryCatch class instance for things, so I think this solution works best.

[Lms24]

@AbhiPrasad yes I was also thinking about adding a protected field to the original TryCatch that the Angular specific one could override. I added this under "Up for Discussion" in #5194 for v8.