RUM-5762 [SR] Create touchPrivacyLevel masking option

[mariedm]

What and why?

This PR is the first step towards providing more granular control over global masking in Session Replay. It introduces a new privacy level for user touches (e.g., tap, swipe), allowing customers to choose whether to show or hide these touches in replays. Currently, touches are always visible.

For full context, refer to the RFC.

How?

This PR establishes the new privacy level within the Session Replay Configuration but does not yet implement the logic for touch visibility in snapshots.

Future PRs will introduce additional privacy levels for images, text, and user inputs. The current Privacy Level will be deprecated once the global masking feature is fully implemented and released.

This PR:

• Creates an enum for SessionReplayTouchPrivacyLevel
• Adds a new initializer for SessionReplayConfiguration that accepts the new touchPrivacyLevel
  • The new API for initializing SessionReplayConfiguration uses a mandatory sampleRate parameter and an optional touchPrivacyLevel parameter, whereas the former initializer uses a mandatory replaySampleRate parameter and an optional defaultPrivacyLevel. This change in parameter naming was necessary to avoid ambiguity in method calls.
• Updates various tests accordingly

Review checklist

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

[mariedm]

General question: is this the sort of PR to add to the CHANGELOG, given that it provides a new public API?

[maxep]

General question: is this the sort of PR to add to the CHANGELOG, given that it provides a new public API?

Lets not exposed the public config while in progress 👍

[mariedm]

Lets not exposed the public config while in progress

@maxep right! Actually I was planning to keep this on a feature branch until the end but I forgot when submitting this PR. I just changed the base branch.

Do you think I should still make this new API private in the meantime?

[mariedm]

Following our discussion on Slack, I've updated the new API. We’re keeping the same parameter name for replaySampleRate and requiring users to explicitly pass the new privacy levels. This remains a non-breaking change solution, and we can always introduce some default values for the new API in a future major version.

An action item has been added to the Changes For Next Major Version (internal) to remove the former initializer.