fix(sessions): Move and flush unfinished previous session on init

[romtsn]

📜 Description

• Previously, we were waiting on previous session flush latch on our background queue when processing ANRs or finalizing previous session for 15 seconds to give it a good chance to be flushed. However, the trigger for the flush was actually a new session start:

  • We start a new session on foreground
  • We see that there's an existing unfinished session
  • We move it to its own file
  • We flush the latch
    However this was not working well for background app starts. Since there's no foreground event, a new session would not be started and we were waiting for 15 seconds for nothing (on a background thread, but still). So this PR addresses it by moving any unfinished session to its own file right away on init (but before any of the integrations are registered, so those that rely on the previous session latch (like ANRs), do not need to wait for it).

• We also just rename session.json to previous_session.json now, as opposed to ser/deserializing the session multiple times from/into different files

Before (perfetto trace of a background app start)

After (perfetto trace of a background app start)

💡 Motivation and Context

Speed up things on our background queue

💚 How did you test it?

Manually + automated

📝 Checklist

• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

[romtsn]

@markushi I'm unsure about how this affects the Hybrid SDKs, but form a quick look into InternalSentrySdk I don't think anything needs to change. But let me know if there's something I missed.

[seer-by-sentry]

Potential bug: If `renameTo` fails in `movePreviousSession`, a latch is still released, causing `PreviousSessionFinalizer` to proceed and silently lose the session data.

• Description: The movePreviousSession method in EnvelopeCache attempts to rename the currentSessionFile. If this renameTo() operation fails due to filesystem issues or permissions, it only logs a warning. However, it proceeds to call flushPreviousSession(), which releases the previousSessionLatch. The PreviousSessionFinalizer is dependent on this latch. Once unblocked, it attempts to process the previous session but fails to find the file because the rename operation was unsuccessful. This results in the session data being silently and permanently lost, which can affect the accuracy of analytics and crash reporting.
• Suggested fix: Check the boolean return value of currentSessionFile.renameTo(previousSessionFile). If the rename operation returns false, do not call flushPreviousSession(). This will prevent the PreviousSessionFinalizer from proceeding prematurely and allow for proper error handling or retry logic for the failed file operation.
  _{severity: 0.82, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	400.64 ms	444.39 ms	43.75 ms
Size	1.58 MiB	2.09 MiB	522.37 KiB

[markushi]

LGTM, left a comment about edge case handling.

[markushi]

I'm wondering if we should simply overwrite the file instead. If the file still exists, chances are that we've already sent that session information. On the other hand currentSessionFile was never flushed, so renaming it to previousSessionFile and later flushing that session feels more correct.