feat: profile concurrent transactions

[armcknight]

We currently only profile one transaction at a time–if subsequent transactions are begun, only the first will be profiled. Now we will start the profiler for a transaction, and keep it running until the last stacked transaction is finished.

This PR also moves the growing amount of profiling-related code from SentryTracer.m back into SentryProfiler.mm. There are three methods there that the tracer calls:

• + [SentryProfiler startForSpanID:hub:]: will start a profiler if there's not one already running, and add the span id to the profiler's list of concurrent transactions it's tracking
• + [SentryProfiler stopProfilingSpan:]:
  - if the provided span id is the last one being profiled, stops the profiler
  - otherwise, remove that span from tracking and continue profiling
• + [SentryProfiler linkTransaction:]: grabs the appropriate profiler instance waiting on this transaction for a span it was profiling, and captures an envelope with the data it has gathered if it was the last transaction it was waiting on

Also moved the call to stop the profiler to after another early return in - [SentryTracer finishInternal:], which I wonder if this was causing premature stoppage of the profiler when UI event tracking was enabled, which I first noticed in the benchmark tests: https://github.com/getsentry/sentry-cocoa/pull/2105/files#diff-84fda3cf94bf21dd7ceabf3c0ced60d74c124620d5a8dfdd3b8661563a79ec49R447. Similarly, also moved the call to capture the profiling envelope there until after the early return that drops transactions due to pre-warm durations (with a function to do so: + [SentryProfiler dropTransaction:])

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time (ms)	1260.65	1274.22	13.57
Size (bytes)	21157	332695	311538

[philipphofmann]

@armcknight, can you please elaborate on why profiling uses mach_absoluate_time/clock_gettime_nsec_np(CLOCK_UPTIME_RAW)? I just gave this PR a glance because still WIP.

[armcknight]

@philipphofmann I left some details in a previous comment on the timestamp stuff, but basically, that API does not have a fixed reference date like NSDate does, so they can't be compared against each other, but I needed to get the relative timestamps of transactions that are linked to a given profile.

[armcknight]

Oh but you asked why profiling uses the system time instead of NSDate... I think because it's guaranteed to be monotonic whereas NSDate is not, and it's also much faster than NSDate, just a syscall vs alloc/initing new class instances. Check out https://kandelvijaya.com/2016/10/25/precisiontiminginios/

[github-actions]

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

Generated by 🚫 dangerJS against 573b656

[brustolin]

First pass, it looks good.
A few comments to address.

[philipphofmann]

Just gave this a quick glance, will do a full review on Monday.

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1235.86 ms	1250.59 ms	14.73 ms
Size	20.51 KiB	335.49 KiB	314.98 KiB

Baseline results on branch: master

Startup times

Revision	Plain	With Sentry	Diff
5025d2e	1248.52 ms	1251.72 ms	3.20 ms
b869536	1250.37 ms	1274.84 ms	24.47 ms
5025d2e	1245.14 ms	1268.58 ms	23.44 ms
4a66f00	1259.84 ms	1281.66 ms	21.82 ms
4a66f00	1224.73 ms	1241.14 ms	16.41 ms
9fc2dd0	1246.14 ms	1275.00 ms	28.86 ms

App size

Revision	Plain	With Sentry	Diff
5025d2e	20.51 KiB	331.79 KiB	311.28 KiB
b869536	20.51 KiB	331.79 KiB	311.28 KiB
5025d2e	20.51 KiB	331.79 KiB	311.28 KiB
4a66f00	20.51 KiB	331.79 KiB	311.28 KiB
4a66f00	20.51 KiB	331.79 KiB	311.28 KiB
9fc2dd0	20.50 KiB	331.79 KiB	311.28 KiB

Previous results on branch: armcknight/profile-concurrent-transactions

Startup times

Revision	Plain	With Sentry	Diff
0264ffd	1202.52 ms	1240.36 ms	37.84 ms
586e4e8	1201.44 ms	1237.12 ms	35.68 ms
1db0272	1201.75 ms	1245.74 ms	43.99 ms
c7ab130	1237.20 ms	1242.43 ms	5.22 ms
962039b	1227.00 ms	1252.12 ms	25.12 ms
e951eb0	1198.49 ms	1228.20 ms	29.71 ms
fb3beab	1234.20 ms	1248.73 ms	14.53 ms

App size

Revision	Plain	With Sentry	Diff
0264ffd	20.51 KiB	335.71 KiB	315.21 KiB
586e4e8	20.51 KiB	335.71 KiB	315.21 KiB
1db0272	20.51 KiB	335.71 KiB	315.21 KiB
c7ab130	20.51 KiB	335.71 KiB	315.20 KiB
962039b	20.51 KiB	335.72 KiB	315.21 KiB
e951eb0	20.51 KiB	335.71 KiB	315.21 KiB
fb3beab	20.51 KiB	335.71 KiB	315.21 KiB

[philipphofmann]

This is going to be a cool feature and looking forward to seeing this PR merged. I added a couple of comments.

[armcknight]

@philipphofmann here are the changes to the test code that I moved from the hub tests to the new profiler swift tests. RE #2105 (comment)

[philipphofmann]

I think the race condition still is possible, and I have a few concerns about the tests.