feat: Add attrUnmaskAllowlist RUM config option

[andrewatwood]

Motivation

When masking is enabled, RUM automatically masks all data-* attributes to prevent data leakage and slim down replay frame payloads. However, some UI libraries use CSS selectors that target certain data-* attributes and values, which can lead to breakage of styles and rendering issues during replay playback. We need a way to maintain these styles during playback and this seems like a relatively straightforward way to do so.

I thought about making this a map of attributes and allowed values for each attribute, but wanted to keep the surface of the checks small. There may be some perf optimization needed for such a high-frequency check but tested this as a proof-of-concept locally and saw the results I was after, so just starting with this base implementation to get a temperature check on a feature like this.

Changes

• Adds a attrUnmaskAllowlist option to the RUM configuration
• Reads from this list when present to determine masking behavior for attributes

Test instructions

• Create an element with CSS rules targeting specific data-* attribute values (ie. data-state=open)
• Initiate a RUM session with replay enabled and no attrUnmaskAllowlist provided
• Verify that the replay does not render the intended styles due to masking the attribute value
• Update the config to include a relevant attrUnmaskAllowlist
• Verify that the next replay DOES render the intended styles due to preservation of the attribute value

Once again I will likely need integration test help as I'm unable to run suites beyond the unit tests.

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[sethfowler-datadog]

Hi @andrewatwood, I want to thank you for your contribution! I agree that this would be a very useful feature to have.

We have internal processes of design review and validation that are particularly important for privacy-related features. For that reason, unfortunately, it's generally not feasible for an external contributor to directly contribute new features in this area. We need to be careful, both because it's very important to get privacy right, and because backwards compatibility is particularly challenging in privacy-related contexts.

With all that said, I certainly see the opportunity for improvement here; we will investigate it further. If you would be willing to open a support ticket regarding this feature and share some examples of session replays that would be improved if we had it, that would be quite helpful. Please feel free to mention my Github username in the ticket; that should help it to reach me a little faster.