add SessionIdEventSender and wire up into lifecycle

[breedx-splk]

This is a follow-up from #564. It reintroduces the SessionIdEventSender class and wires it up at build() time.

I know there's some hesitation to put "opinionated" session behavior into the core module. I'm open to discussion and ideas here, but I do think that:

• It's important that the initial Session be created as early as OpenTelemetryRum can allow. Right now that happens with the builder. This is important for several reasons, not the least of which is that we want telemetry to be associated with the current session.
• It's important to generate the session.start event as close to the session actually being started/created.
• The session.start event can't be created until after the otel sdk is created.

[LikeTheSalad]

This seems a bit forced. I'm guessing it will happen naturally when the first telemetry event is recorded, is there a reason why we must start the session earlier?

[marandaneto]

probably needed if we want a session to be active as early as possible.
eg SDK is initiated during the Application#onCreate class.
If the session starts (automatically) when the OS gets a notification that the app is in the foreground (using androidx.lifecycle), that might be too late because the whole Application#onCreate code has been run, maybe some telemetry data was collected, but there was not an active session yet, in this case, makes sense that the SDK starts as session ASAP.

[LikeTheSalad]

Also, if we must do it earlier than the first telemetry event, which I guess would depend on the definition of a session, for example, if the definition ends up telling something around the lines of "the session starts when the app is launched", then I think the initialization of the SDK is too late to do so as well. It reminds me of the app launch timer that was recently mentioned here, where we might have to come up with some other mechanisms to track the start time temporarily until the Otel instance is ready.

[LikeTheSalad]

maybe some telemetry data was collected, but there was not an active session yet

The session is queried and applied in the processors, so it will start as soon as the first telemetry data is collected. We do have an exception though where we collect events before the SDK is finished initializing which is here in the startup instrumentation where we store events in memory until those can be sent after the SDK is ready. It's probably worth considering a similar solution for this case in case we really need to trigger the event before the first telemetry data is collected.

[bidetofevil]

I too think the first session should start as early as possible, but if the OTel SDK isn't started, can we even do anything with it? If we simply initialize it lazily when an instance of the processor is created, it should ensure that every piece of OTel telemetry recorded will have a session ID?

[marandaneto]

should the sessionManager have a start method instead for this use case so it's semantically correct?

[LikeTheSalad]

Regarding what I mentioned in yesterday's meeting about trying to make core as plain as possible, just to expand on it, it's mostly because I feel like that way it'd be easier for both us and potential users with very specific requirements (vendors included) to address everybody's needs. Now, I think we can make some exceptions though, especially for things that we know are a must for everybody, such as disk buffering and/or adding certain Android environment attributes to all telemetry by default. However, when it comes to generating signals (spans, logs, and metrics) automatically I feel like that's where I find it difficult to impose opinions in core because if for whatever reason, given this PR as an example, some vendor or user doesn't use those events later within their oblt dashboard or the like and might also want to save disk space whenever possible, then having these events triggered automatically without a possibility to turning them off could be a problem, for them and later for us too.

Based on the above, if you think that this functionality is a must for everyone and you're willing to argue with any potential user/vendor who might not want it, it honestly sounds a bit exhausting to me 😅 but I guess that's fair. However, before merging this PR I think it might be worth taking a look at this "layered structure" proposal for the repo which might make it easier to add our opinions, without having to enforce them onto power users nor having to create a ton of config flags either to address all kinds of use cases. If we go with such a structure (or a similar one that has a low-level layer and high-level one) then we might be able to have our cake and eat it too, as we'd still add all our "opinions" in the higher-level place and leave the low-level one for our more opinionated users.

[bidetofevil]

Seems like we should have a list of features/instrumentations defined as "must haves" that cannot be opt out of, and another set that are default on, and another that is default off. Do we have a list like that so we can determine where each feature belongs to, so we can better figure out where initialization and configuration should be happening?