feat(core): Extract sampleTransaction method out

[mydea]

This extracts the sampleTransaction method out and exports this from core so we can use it for POTEL (where we build transactions differently).

This is needed for #9085.

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser (incl. Tracing, Replay) - Webpack (gzipped)	84.23 KB (-0.03% 🔽)
@sentry/browser (incl. Tracing) - Webpack (gzipped)	31.4 KB (-0.01% 🔽)
@sentry/browser - Webpack (gzipped)	22 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (gzipped)	78.68 KB (+0.01% 🔺)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (gzipped)	28.5 KB (-0.01% 🔽)
@sentry/browser - ES6 CDN Bundle (gzipped)	20.59 KB (0%)
@sentry/browser (incl. Tracing, Replay) - ES6 CDN Bundle (minified & uncompressed)	254.1 KB (0%)
@sentry/browser (incl. Tracing) - ES6 CDN Bundle (minified & uncompressed)	86.38 KB (0%)
@sentry/browser - ES6 CDN Bundle (minified & uncompressed)	61.23 KB (0%)
@sentry/browser (incl. Tracing) - ES5 CDN Bundle (gzipped)	31.37 KB (-0.02% 🔽)
@sentry/react (incl. Tracing, Replay) - Webpack (gzipped)	84.26 KB (-0.02% 🔽)
@sentry/react - Webpack (gzipped)	22.03 KB (0%)
@sentry/nextjs Client (incl. Tracing, Replay) - Webpack (gzipped)	102.22 KB (+0.03% 🔺)
@sentry/nextjs Client - Webpack (gzipped)	50.98 KB (+0.06% 🔺)

[lforst]

I don't wanna hard block this but is there any chance we can vendor this into the otel SDK? Right now this change just increases API surface and exposes an implementation detail without any real upside to the user.

[mydea]

I don't wanna hard block this but is there any chance we can vendor this into the otel SDK? Right now this change just increases API surface and exposes an implementation detail without any real upside to the user.

I get what you mean, I was also not 100% sure. IMHO it is not super trivial code, we can of course copy this into node-experimental but since the trajectory for this is rather that we prob. want to expand on the POTEL stuff, I feel eventually we do not want to duplicate this as they should behave the same in both scenarios, we don't want them to drift apart 🤔

Personally, I would argue that the API that is exported from @sentry/core is really mostly designed to be used by us, not by users, so I'd say it's OK (I would not export this from e.g. @sentry/browser or @sentry/node). What do you think?

[lforst]

I would argue that the API that is exported from @sentry/core is really mostly designed to be used by us

That doesn't really matter. Anything that is publicly exposed is a pain to refactor from that point onwards. You can't remove it, change params, rename it, ... . @sentry/core needs to follow semver. Any third party SDK depends on it.

But as I said, I don't wanna hard block. I just wanted you to think about it so: rubber stamp.