Session expire based on user inactivity

As discussed in this week's SIG meeting, we should better define the logic/litmus test to tell when a session should expire.

Current state

What we're doing

We split the app's usage into 2 states:

1. The app is in the foreground.
2. The app is in the background.

Based on that information, we make decisions on when to make a session expire by following these rules:

• When the app is in the foreground, the session can only expire after 4 hours.
• When the app is in the background, the session has a timeout of 15 minutes to expire, unless the state goes back to "foreground" before that.

How we're doing it

The underlying mechanism we use to tell each state is by registering an observer into the ProcessLifecycleOwner and deciding that the state is the number 1 when the ON_START event is received, and then switching to state number 2 when the ON_STOP one is received.

Why we're doing it

When discussed in the SIG meeting, it seemed like the idea behind this behavior is to make sure that we're grouping telemetry in a session only when a user is interacting with the app, so that sessions can only track real user activity.

Proposed changes

State names changes

Replace the FOREGROUND/BACKGROUND states with something that better conveys what we want to achieve, such as:

1. The app is in the foreground -> The user is active.
2. The app is in the background -> The user is inactive.

Configurable state litmus test with simple default behavior

One of the issues with the current approach is that it assumes that the user might not be interacting with the application because the app is in the background (i.e. there are no visible activities). This might not always be true for all apps, such as those that provide notifications with action buttons, commonly used in media streaming apps.

Because of that, one idea proposed during the SIG meeting was to provide a way for our users to "signal the session manager" that the user is active or not, so that we don't have to make that decision on behalf of every app use case. For convenience, we'd come up with a default behavior to tell when a user is active or not, that should work for most apps.

Some ideas for the default behavior are:

• Keep using the FOREGROUND/BACKGROUND callbacks as a way to tell whether a user is active or not.
• Always have a timeout that gets reset when telemetry is created, while keeping the 4 hour max time to live for a session.

Start by tracing the session manager's ProcessLifecycleOwner observer and its ON_START/ON_STOP handling. Clarify the chosen active/inactive litmus test and user signaling API, then define completion around renamed states, configurable behavior, and the existing timeout rules.