Instantiate continuous profiling v8 (p3)

[stefanosiano]

:scroll: Description

added profile context to SentryTracer removed isProfilingEnabled from AndroidContinuousProfiler, as it's useless added continuous profiler to SentryOptions added DefaultTransactionPerformanceCollector to AndroidContinuousProfiler and updated it to work with string ids other than transactions fixed ProfileChunk measurements being modifiable from other code added thread id and name to SpanContext.data

#skip-changelog

:bulb: Motivation and Context

Instantiate Continuous Profiler Part 3 of https://github.com/getsentry/sentry-java/pull/3710

:green_heart: How did you test it?

Unit tests

:pencil: Checklist

• [ ] I reviewed the submitted code.
• [ ] I added tests to verify the changes.
• [ ] No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• [ ] I updated the docs if needed.
• [ ] Review from the native team if needed.
• [ ] No breaking change or entry added to the changelog.
• [ ] No breaking change for hybrid SDKs or communicated to hybrid SDKs.

:crystal_ball: Next steps

[github-actions[bot]]

	Messages
:book:	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by :no_entry_sign: dangerJS against 6639591647e4286b72672f8e6d6412ebca88c7b3

[github-actions[bot]]

Performance metrics :rocket:

	Plain	With Sentry	Diff
Startup time	415.45 ms	426.16 ms	10.71 ms
Size	1.65 MiB	2.31 MiB	677.69 KiB

Baseline results on branch: feat/continuous-profiling-part2

Startup times

Revision	Plain	With Sentry	Diff
4e27f0d5ed7cedb484dac0896fc415b5178f6fa7	425.02 ms	452.80 ms	27.78 ms
ae2da55b2efd50458eeba8a9262eff94059a245e	448.49 ms	482.66 ms	34.17 ms

App size

Revision	Plain	With Sentry	Diff
4e27f0d5ed7cedb484dac0896fc415b5178f6fa7	1.65 MiB	2.31 MiB	674.06 KiB
ae2da55b2efd50458eeba8a9262eff94059a245e	1.65 MiB	2.31 MiB	674.06 KiB

[stefanosiano]

LGTM, but one comment about where we send profiler_id:

• I don't know about backend implications, but why don't we make profiler_id part of the baggage/trace-header? I'd imagine it'd make sense to have it there to make sampling decisions for spans/txs etc etc, or is it already supposed to work with spans-without-sampling? Just did the same thing for replays recently, that's why I'm asking, because there it differs from this approach a little.

Chunks are not bound to traces at the moment, but I agree on your thoughts. We should probably do it at some point, and then we'll revisit this, but not now sadly