…ns()` (#10243)

The current implementation has two problems:

1. It is weird that you can accidentally mutate the default integrations
of another package
2. We sometimes have logic-based default integrations - e.g. adding an
integration only if tracing is enabled, or similar. This means that
either we have to add some logic in the _upstream_ SDK to ensure this is
still added even if downstream SDKs overwrite default integrations, or
we need to duplicate the logic in the _downstream_ SDKs. With this new
method, we can instead centralize this, and downstream SDKs simply need
to call upstream `getDefaultIntegrations(options)`.

The usage of this was not really working well to begin with, and even
worse with the new functional integrations. Because if the user adds the
integration themselves (e.g. `integrations: [new RewriteFrames()]`), it
will not actually get the correct iteratee at all.

Overall it is much cleaner anyhow to just fork the integrations properly
and use them instead of the default one - then we can rely on the
standard behavior of merging integrations etc.

We need to do the same for basically all usages of
`addOrUpdateIntegration`, as that actually does not work at all anymore
with the functional integrations 😬 (and in many instances never really
worked properly if users passed in a custom integration themselves).

Co-authored-by: Abhijeet Prasad <aprasad@sentry.io>

We should wait for
#10243 to merge this,
as otherwise we'll get a deprecation/eslint error there.

[Gitflow] Merge master into develop

There have been tries to do this before, but let's see how things stand
today...

Deprecate the `Span.parentSpanId` field on the interface and class. 

This required only a couple of code replacements and a bunch of test
adjustments. Also went ahead and changed the integration test event type
in the tests I was modifying.

…bute (#10260)

Deprecate the `Span.origin` field on the class and the
interface. It will be replaced in v8 by the semantic `sentry.op`
attribute.

We should think about moving the wasm integration into `@sentry/browser`
and removing `@sentry/wasm` all together. What do you think?

By using functional integrations in #10230, we started importing from
`@sentry/core` in the WASM integration. However, we didn't register
`@sentry/core` as a dependency, making rollup bundle core into the
package output. This changed the `build/npm` directory structure, making
our entry points in `package.json` invalid.

This PR fixes things by simply registering core as a dependency of wasm.
If we move WASM to core (which I strongly think we should do), we'll be
able to get rid of this again.

… API (#10085)

Move `parameterize` function to core, export it to upstream packages via browser and node.

Co-authored-by: Luca Forstner <luca.forstner@sentry.io>

Instead, users should use the new functional styles.

Note that we'll probably actually un-deprecate `Replay` in some form in
v8, as we'll be keeping the class around there for sure (as there is a
lot of logic in there...). But users should not use it, so deprecating
this now!

While at it, I also deprecated the old `InitSentryForEmber` method in
favor of `init()`.

It's slightly unfortunate that I missed this, but we probably shouldn't
have exposed `ReplayCanvas` as a class anymore at all 😬 maybe we wait
before we document this etc. until we merged the functional style. cc
@billyvg

…OrUpdateIntegration` (#10263)

This updates the last usage of `addOrUpdateIntegration` and deprecates
it.

Adds ability to configure all border radiuses on feedback widget

Closes #10256

…nt` (#10296)

Currently, you can use `Sentry.getClient() !== undefined` to check if
Sentry was initialized. In v8, we want to change this so that this
_always_ returns a client (possibly a Noop client), so this check will
not work anymore there. Instead, we can provide a new util that does
this explicitly, where we can control what it checks under the hood.

As per
https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming/responseStart,
`responseStart` can be 0 if the request is coming straight from the
cache. This might lead us to calculate a negative ttfb.

To account for these scenarios, use `Math.max` to make sure we always
set to 0 in the case of a negative value.

meta(changelog): Update changelog for v7.95.0