Stop sessions if app goes into background

[AbhiPrasad]

Problem Statement

https://develop.sentry.dev/sdk/sessions/

In the mobile SDKs, we end a session if the app is backgrounded for > 30s, and start another one if the app is foregrounded after that.

We might want to explore adding this functionality for Electron sessions.

Solution Brainstorm

We can perhaps add this as an option to the main session integration and have it be opt-in. This way people's dashboards will not dramatically change when bumping SDK versions, and we can re-evaluate what the default should be when we bump the major version.

[smeubank]

i'm afraid I am not so familiar with the release health sessions data model. This reminds me of issues with idle transactions in react-native and similar client side platforms. Where we need to basically have a span(s) which represents background time which can be subtracted from aggregate time and in UI when relevant to compress

[souredoutlook]

The customer interaction that prompted this issue included the following pain points:

• because the (default) behaviour for Sessions in electron is to send on Main Process Exit or Main Process restart it does not accurately model very long running sessions in real time but is instead a lagging indicator
• sending sessions with the newly introduced behaviour in the PR that closed Sending initial session when created #713 does provide real-time data but only for sessions where the main process is not running for longer than our event sourcing model for session updates allows (5 days)
• if such an algorithm as the one proposed in this issue is adopted we need to be able to answer the following questions: What happens when the application crashes in the background? What methods can we use to avoid recording unhandled errors form contributing to sessions running in the foreground that don't exit the main process (aka don't actually crash).