Make EventProcessors async

[linear-code]

I investigated how we could approach this and ended up with two variants:

• A. Moving work to background thread
• B. Adding EventProcessor.processAsync methods

A. Moving work to background thread

Problems:

• Some EventProcessor work can't be moved to background since we need the current state at time of capture. Adding a queue and delaying things like screen shot capture and view hierarchy would potentially show the wrong data.
• It's hard to find a good spot to move work to background since we currently use scope very far into SentryClient. While we could work around this, that also comes with risks. Cloning scopes to snapshot them could introduce more overhead than we are removing. Handpicking values we need could turn into a maintenance nightmare and cause lots of bugs.
• Using scope async might cause problems due to customers removing things from scope right after capture went through when async processing hasn't run yet. When async processing finally runs, the info is already gone or has been updated to different state.
• beforeSend callbacks are moved to background thread, we'd need an option to allow customers to opt-in until the next major and then flip to default on

I abandoned this idea due to some work that we can't push to background without risking a broken SDK.

B. Adding EventProcessor processAsync variants

Problems:

• Introduces another Queue we have to maintain including overflow and it creates a new dedicated thread.
• beforeSend callbacks are moved to background thread
  • We can add an option isEnableAsyncProcessing which we'll default to false until the next major, then we can flip it and document the breaking change. Customers should be able to move some of their beforeSend code to an EventProcessor so they can still access ThreadLocal state.

How it works:

• One processAsync method mirroring each existing process method on EventProcessor, so 5 new methods in total.
• A new option enableAsyncProcessing that defaults to false until the next major. We can then document the breaking change, flip to true and add guidance on how to migrate existing use cases from beforeSend to sync EventProcessor methods + beforeSend combo.
• If isEnableAsyncProcessing is true we use a Queue backed by a single thread to move processing to background right before where we currently call beforeSend. We first call processAsync on all event processors, then beforeSend, both from the background thread.
• If isEnableAsyncProcessing is false we still call processAsync before beforeSend but do so without moving to a background thread. There is no Queue and no extra thread.

What doesn't make sense:

• Adding a supportsAsync method to EventProcessor interface and caching the result. The default behaviour of simply returning the incoming event is faster. I tested and it slowed down the SDK. There's also a risk of leaking memory via the cache if customers keep adding short lived event processors.

[linear-code]

JAVA-529

[linear-code]

from alexanderdinauer:

Benchmark results:

With asyncProcess methods added to EventProcessor, we're slowing down first capture by default since isEnableAsyncProcessing is false (until the next major). Only when setting isEnableAsyncProcessing to true we're seeing a benefit. Note: for this statement I've already moved DeviceInfo retrieval from DefaultAndroidEventProcessor ctor to lazily loading it on first use in processAsync.

This is just a single improvement. In the future we can also move more code to processAsync, likely further improving timings when async processing is enabled.

Benchmark attempts for small app:

• AR02: small app, isEnableAsyncProcessing set to false
• AR03: small app, isEnableAsyncProcessing set to true

Benchmark attempts for more realistic app:

• AR12: realistic app, isEnableAsyncProcessing set to false
• AR13: realistic app, isEnableAsyncProcessing set to true

For the more realistic app, my explanation is that there's some capture (likely a transaction) happening before our "first capture" benchmark runs so it isn't really the first capture anymore.

[linear-code]

from alexanderdinauer:

Draft PR used for benchmarking: #5558

[linear-code]

from alexanderdinauer:

Since this just came up, I also benchmarked adding processAsync + option etc. but not moving DeviceInfo from the dedicated executor in DefaultAndroidEventProcessor ctor: