…8270)

In our (still internal) `trace` function, we don't yet check if
`hasTracingEnabled` returns `true` before trying to start a span or a
transaction. This leads to the following problematic UX path that was
discovered
[here](#5838 (reply in thread)):

1. Users don't set `tracesSampleRate` (or `tracesSampler`), causing some
SDKs (NextJS, SvelteKit) to **not** add the `BrowserTracing`
integration, which in turn means that tracing extension methods are not
added/registered.
2. Users or, more likely, other parts of our SDK (e.g. SvelteKit's
wrappers/handlers) call `trace` which will still try to start a
span/txn.
3. Users will get a console warning that tracing extension methods were
not installed and they should manually call `addExtensionMethods` which
is completely misleading in this case.

This fix makes `trace` check for `hasTracingEnabled()` in which case it
will not start a span but just invoke the error callback if an error
occurred.

#8369)

Previously, in our Angular routing instrumentation, we only stopped
routing spans when a navigation ended successfully. This was because we
only listened to
[`NavigationEnd`](https://angular.io/api/router/NavigationEnd) router
events. However, the Angular router emits other events in unsuccessful
routing attempts:
* a routing error (e.g. unknown route) emits
[`NavigationError`](https://angular.io/api/router/NavigationCancel)
* a cancelled navigation (e.g. due to a route guard that
rejected/returned false) emits
[`NavigationCancel`](https://angular.io/api/router/NavigationCancel)

This fix adjusts our instrumentation to also listen to these events and
to stop the span accordingly.

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 fix 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](#5417 (comment))
obsolete.

Since @sentry/sveltekit depends on @sentry/vite-plugin, which in turn
depens on `@sentry/node@^7.19.0` & `@sentry/tracing@^7.19.0`, this fails
to install in E2E tests for pre-release versions (e.g. `7.57.0-beta.0`),
as the prerelease does not satisfy the range `^7.19.0`. So we override
this to `*` to ensure this works as expected.

…8368)

This field was added as part of v7.56.0, but `SlowClickFrameData` was
created before that. Having `clickCount` be required breaks backwards
compatibility, it should be optional.

…s valid (#8381)

In the client-side SvelteKit fetch instrumentation, our previous type
cast when retrieving the SDK client was wrong, causing us to not guard
the fetch instrumentation correctly if the client was undefined. This fix
adds an undefined check.

fixes #8290

…tions` from SDK (#8382)

When refactoring our `@sentry/tracing` package and exporting tracing
related integrations from SDK packages, we apparently forgot to export
`autoDiscoverNodePerformanceMonitoringIntegrations` from the Serverless
SDK. This fix re-adds the export.

…8362)

…8383)

It seems in some environments `sessionStorage` my be unset to `null` or
similar. To be extra careful, we can guard for existence as well there.

Fixes #8392

This PR adjusts the exception name generation for non-error objects in
the browser SDK.

ref #7941

Add https://eslint.org/docs/latest/rules/no-return-await to eslint
config to remove usage of uneeded async/await calls. This helps reduce
microtasks being generated, which can help reduce memory pressure caused
by the SDK.

The downside of removing `return await` is that stacktraces get slightly
worse for async errors that use these methods, as we no longer pause
execution on return for the engine to grab context on, but instead just
pass through the promise, but I think it's worth it for this to be the
default, and for us to opt-in to the better stacktraces if need be.

When running `yarn build:watch` I found some circular deps:

```
src/eventBuffer/index.ts -> src/eventBuffer/EventBufferArray.ts -> src/eventBuffer/index.ts
src/eventBuffer/index.ts -> src/eventBuffer/EventBufferProxy.ts -> src/eventBuffer/EventBufferCompressionWorker.ts -> src/eventBuffer/index.ts
```

This refactors the `EventBufferSizeExceededError` export to remove that.

…mentation (#8391)

As outlined in
#8174 (comment),
our current SvelteKit fetch instrumentation breaks SvelteKit's request
caching mechanism. This is problematic as `fetch` requests from
universal `load` functions were made again on the client side during
hydration although the response was already cached from the initial
server-side request.

The reason for the cache miss is that in the instrumentation we add our
tracing headers to the requests, which lead to a different cache key
than the one produced on the server side.

This fix vendors in code from [the SvelteKit
repo](https://github.com/sveltejs/kit) so that we can perform the same
cache lookup in our instrumentation. If the lookup was successful (-->
cache hit), we won't attach any headers or create breadcrumbs to 1. let
Kit's fetch return the cached response and 2. not add spans for a fetch
request that didn't even happen.

This change ensures that browser profiles are sent in the same envelope
as transactions and enables sourcemap support.

Added an integration test application using [Remix
1.17.0](https://github.com/remix-run/remix/releases/tag/remix%401.17.0)
and [v2 future
flags](https://remix.run/docs/en/main/pages/api-development-strategy) to
see the state of current SDK support for v2.

ref #8352

As we work toward adding tracing without performance support, this PR
updates the `BrowserTracing` integration to use and favour the top level
`tracePropagationTargets` option if it exists.

This option was made top level in
#8395

`tracePropagationTargets` is now part of the unified API for distributed
tracing. It's also expected that electron/react native will behave the
same way as well. This also leaves us the flexibility to extract tracing
out of BrowserTracing, or create a new integration that just does
tracing but no performance monitoring.

We can make sure this migration is smooth and easy to understand with a
good set of docs, which is what I will be working on next. In these docs
changes, we'll be updating the automatic instrumentation sections, and
formally documented `tracePropagationTargets` as a high level option.

Collect span information on how long the async calls to profiler.stop
take which will help us evaluate if calling txn.finish after
profiler.stop is a viable approach

This adds an experiment that will allow http timings to be captured. We
currently capture timings on Sentry SaaS with some custom code and
append them to the spans, which has been helpful to identify some
performance problems that were previously hidden (http/1.1 stall time).
Following this work we can add these to the waterfall to represent
measurements as subtimings and will power an upcoming http/1.1 stall
performance issue.

This updates the TS version we use from 3.8.3 to 4.9.5. This allows us
to use newer TS features, as well as as improves compatibility with
newer @types/xxx packages that use newer features, which leads to issues
when transitive dependencies are used etc.

We use [downlevel-dts](https://www.npmjs.com/package/downlevel-dts) to
generate a 3.8 compatible types output _in addition_, so this should be
fully backwards compatible. TS provides a built-in way to tell it to use
a certain types output for a certain version, so this should work with
no breaking change.

The main changes necessary here are small tweaks to types which are
required in 4.9.x.