Improve instrumentation consistency and deduplicate vitals between performance<->replay

[k-fish]

Now that tracing-internal has been split out from the tracing bundle, we have a bunch of flat functions for both collecting vitals and creating performance entries. We collect LCP currently in tracing-internal package here:

sentry-javascript/packages/tracing-internal/src/browser/metrics/index.ts

Line 137 in c9aaf8b

function _trackLCP(): ReturnType<typeof onLCP> {

It should be possible now for Replay to make use of the same code instead of having separate LCP collection etc.
eg.

sentry-javascript/packages/replay/src/util/createPerformanceEntries.ts

Line 145 in c9aaf8b

function createLargestContentfulPaint(

sentry-javascript/packages/replay/src/util/dedupePerformanceEntries.ts

Line 53 in c9aaf8b

// We want the latest LCP event only

This may mean tracing-internal needs to open some hooks or check for the replay integration since replay will have specific replay-only information they may wish to append to the spans, or may wish to collect some performance information and process it further, but the actual measurement creation can now be shared.

[k-fish]

@AbhiPrasad / @billyvg for some reason I don't see teams for assignment, feel free to ping whoever. I really don't see a reason we can't get rid of a bunch of this duplicate code. I think the interop between replay<->tracing is pretty light too, just some rrweb metadata enhancement? If data needs to be cloned for now, the replay integration can potentially receive the perf entries and process them.

[AbhiPrasad]

We probably want to have something similar to instrument we expose that both replay and tracing consume:

sentry-javascript/packages/utils/src/instrument.ts

Line 51 in c9aaf8b

function instrument(type: InstrumentHandlerType): void {

I think there is value in building the common set of utilities, we just need to figure out where they live. Might make sense to just create a temporary browser-utils package that both replay and tracing-internal consumes for now until we properly clean up all the dependencies for v8.

[k-fish]

Might make sense to just create a temporary browser-utils package that both replay and tracing-internal consumes for now until we properly clean up all the dependencies for v8.

That makes sense to me.

What do we want to do in terms of enhancement? Is checking for an integration via the hub an alright way? It wouldn't impose any bundle / import cost since it could look for an integration by name...

[AbhiPrasad]

it will probably just have to be a separate global that instruments once, and then dispatches to any integration listening for the data. The first time it's called it'll set everything up, subsequent patches are just will attach listeners.

We also have hooks that the integrations themselves can fire/listen for more granular dispatch now if that doesn't work.