[WIP] feat(replay): Add experimental dropRepetitiveMutations

[chargome]

Adds a new experimental flag dropRepetitiveMutations to the replay integration options.

When enabled:

• Adds a WeakMap to track recent mutations per DOM node
• Adds mutation fingerprinting to detect identical mutations
• Filters out duplicate mutations within configurable time window

ref #11517

[billyvg]

I'm wondering if we move this logic to be after rrweb processing (e.g. when we add to our event buffer). A [potentially big] downside is that we will always process the mutation w/ rrweb. I don't remember what the mutation records that the onMutation handler looks like (iirc they are just entries from MutationObserver), but will it be able to handle the case where we have the same set of dom elements that get removed and then readded?

A benefit of moving is that it'd be easier to test and verify changes -- we have example replays of different causes of infinite mutations to build against and we can use existing "normal" replays as inputs to our function to check correctness.

Maybe it's even possible to translate between the two (pre and post). WDYT?

[chargome]

will it be able to handle the case where we have the same set of dom elements that get removed and then readded?

I think for this we would need to update the fingerprint logic in the pr to check on the removed and added nodes.

I'm wondering if we move this logic to be after rrweb processing

The testing aspect is def a big upside I would say. But yeah we would still run every mutation through the processing pipeline. Can you point me to some of the example replays, I would need to check how to convert them into tests

[billyvg]

The testing aspect is def a big upside I would say. But yeah we would still run every mutation through the processing pipeline. Can you point me to some of the example replays, I would need to check how to convert them into tests

Yeah i'll work on finding new examples as the ones I had are out of retention now.