RUM-5536 [SR] Start / Stop API

[mariedm]

What and why?

This PR adds the ability for customers to:

• Start and stop a recording
• Disable automatic recording when enabling Session Replay

See RFC for more details.

How?

• Introduce a new startRecordingImmediately optional parameter when enabling Session Replay, defaulting to true
  • A new field has been added for telemetry as well
  • Models have already been updated in #216 and RUM-5598 Update RUM models with startRecordingImmediately #1983
• Add new set of start and stop public APIs to the existing SessionReplay public enum, through static functions
• Introduce a recordingEnabled variable to RecordingCoordinator to track when the user wants to start or stop a recording
• Update the RUM flag has_replay accordingly when starting or stopping a recording
• Modified a bit the logic in RecordingCoordinator:
  • The scheduler is only started if the recording has been enabled by the user and the RUM session is sampled
  • We decouple the update of the has_replay flag from the RUM view ID; whether it's nil or not has no impact on this flag anymore

Note: ignoring webviews' snapshots will be tackled separately

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes

[ncreated]

Looks great 💪 and I appreciate the work on tests coverage 🏅 👌. I left one blocking commend on potential problem in synchronizing the isSampled state (I think now it can be mutated from different threads).

Also, let's move the new option to SessionReplay.Configuration to be consistent with other feature APIs 🙏.

[ncreated]

Looks great 🎯. I left one small feedback on API comment.

[maxep]

Looks great! I have left couple of question/suggestion.

[mariedm]

@maxep Following our discussion, I’ve updated the logic to use the scheduler’s queue. Sharing here the reasoning for later reference.

With this approach, all state changes are synchronized on the same queue. It maintains consistency without the overhead of locks.

A trade-off of this approach is that recordingEnabled is now private to prevent direct access from outside the class, which means we can no longer access it directly in tests. We can still rely on the scheduler’s isRunning variable to verify when the recording is active, though we lose the ability to directly test whether the recording was enabled or disabled by the user.

This change prioritizes thread and synchronization safety, which can avoid hard-to-debug issues. This should save us time and prevent potential problems in the future.

[mariedm]

Note: I logged a ticket to deal with webviews' snapshots later, as this should be an edge case not blocking GA.

[maxep]

Looks great, thanks!