RUM-3458: Fix time drift in RecordedDataQueueHandler

[jonathanmos]

What does this PR do?

Fixes an issue in the RecordedDataQueueHandler where the "current" time was being passed in to the loop, but never updated inside it. This could lead to the time drifting when the queue was very long, leading to items being considered out of date.

Motivation

We have telemetry indicating numerous DataQueueItems are being dropped for being out of date.

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.16%. Comparing base (ee23810) to head (5e3f8b3).
Report is 42 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #2075       +/-   ##
============================================
+ Coverage    67.39%   83.16%   +15.77%     
============================================
  Files          733      495      -238     
  Lines        27028    17752     -9276     
  Branches      4574     2684     -1890     
============================================
- Hits         18213    14762     -3451     
+ Misses        7587     2250     -5337     
+ Partials      1228      740      -488     

Files	Coverage Δ
...nreplay/internal/async/RecordedDataQueueHandler.kt	97.50% <100.00%> (-0.63%)	⬇️
...sionreplay/internal/async/RecordedDataQueueItem.kt	100.00% <100.00%> (ø)
...nreplay/internal/recorder/SessionReplayRecorder.kt	96.80% <100.00%> (+0.19%)	⬆️

... and 288 files with indirect coverage changes

[0xnm]

lgtm. Since we care only about item age at this point, using 2 System.nanoTime() instants is fine and result of this call is monotonically increasing.

However, there is a second timestamp involved, which is attached to the queue item and then used later to build wireframes (nextItem.recordedQueuedItemContext.timestamp), so it is better to have another pair of eyes for the review here, because I'm don't have a deep knowledge of the whole processing pipeline.

[0xnm]

I think it is time to do it: it is a simple change and can be made in another PR