🐛 [RUM-7694] - Keep more ReplayStats history to avoid wrongly marking views as having no replay

[sethfowler-datadog]

Motivation

The browser SDK generates internal metadata about the size of replay data for each view in a data structure called ReplayStats; this helps us debug when something goes wrong. This metadata is also used internally to track whether each view has any replay data at all; when a view update is sent to the server, the ReplayStats data is translated into a flag called has_replay that's used by Datadog's Session Replay UI.

To avoid consuming memory unnecessary, the browser SDK currently only tracks ReplayStats for the last 10 views; the ReplayStats for older views are dropped. This is controlled in the code by the MAX_STATS_HISTORY constant.

Some SPA websites change document.location very quickly, which can cause them to generate new views extremely fast. We've observed that in rare cases, it's possible to generate new views quickly enough that we can end up discarding the ReplayStats for some views before their replay data is sent to the server. This can cause the has_replay flag for these views to be unset, even though they really have replay data; the result is that the view can't be played back in the Session Replay. Obviously that's a problem!

Changes

This PR greatly raises the MAX_STATS_HISTORY limit. The result should be that it will now be practically impossible to trigger this issue, even on sites which change document.location extremely fast.

Eliminating the fixed MAX_STATS_HISTORY limit would likely be a better solution in the long term, and I'll investigate that as a followup, but it's more complicated. This PR should be sufficient to solve the problem from a practical perspective, so it's a good starting point.

Testing

• Local
• Staging
• Unit
• End to end

---

I have gone over the contributing documentation.