Sending from offline caching should be scheduled

[bruno-garcia]

On startup we try to submit cached files. But that's done on the calling thread up to the specified timeout. The goal was to block the calling thread for up to a sensible default, in order to send 1 crash in case the app has a bug that causes it to crash right after starting.

But this blocking of Init to send the event doesn't mean that the calling thread should be use to send the event. In fact, during Init, sending cached events should be scheduled on a background thread, and if the timeout of waiting on Init elapses, Init should return but the background thread should continue to do its job and flush out queued events.

Even if InitCacheFlushTimeout is set to 0, the SDK should then simply schedule flushing these events to Sentry on Init, just not block at all on the Task. This way we don't need to rely on new events happening to capture cached events on app restart.

Docs will need to be updated: https://docs.sentry.io/platforms/dotnet/configuration/options/

i.e:

Setting this option to zero means that Sentry will not wait for events to be flushed before returning from Init, and if the app crashes again before the event is submitted on the background, it's possible events never make it into Sentry for an app that always crashes quickly after startup.

[bruno-garcia]

Relates to getsentry/sentry-java#912 and getsentry/sentry-cocoa#316

[SimonCropp]

we think this is already done. @mattjohnsonpint will investigate

[mattjohnsonpint]

Yes, this was fixed in #1644