RUMM-2029 Reduce the number of intermediate view events in RUM payloads

[ncreated]

What and why?

📦 This PR reduces the number of view events written to RUM batches. With this change, the SDK will send smaller RUM payloads with the same amount of information.

Before, the SDK was issuing a new view update on each significant event spotted in RUM, e.g. new resource stopped or next action tracked. It was allowing similar updates to be written into single RUM payload. In following example, A.1., A.2 and A.3 updates are sent in the same batch, even though their informaton is contained in A.4:

The same applies to B.1. in the second batch.

Current architecture makes it difficult to solve this problem entirely (avoid sending A.1 and B.1). While waiting for V2, this PR applies a partial improvement, which should bring significant benefit with not much cost.

Now, the SDK will skip sending updates which happen too frequently. A basic heuristic is implemented:

• send (accept) view update if it's the first or last update within a view;
• send intermediate view update only if it happened more than 30s after last accepted update.

This removes A.2 and A.3 updates from the sample payload:

How?

I added basic RUMViewUpdatesThrottler which implements described heuristic:

internal protocol RUMViewUpdatesThrottlerType {
    func accept(event: RUMViewEvent) -> Bool
}

It is used in RUMViewScope and samples view events before passing to the writer.

This change has significant impact on RUMMonitorTests.swift, because some of its tests depend on the exact number of view updates. This problem is solved by injecting NoOpRUMViewUpdatesThrottler() into tested monitor. This required a bit of refactoring in RUMMonitor.initialize() sequence - done in two separate commits for easy code review.

Alternatively, instead of using no-op sampler, we could refactor these unit tests to not depend on the number of view updates - in a similar fashion that we did for integration tests in #811. However, knowing that we will soon change RUMMonitorTests significantly for V2, I decided to go with the no-op approach, which seems easier.

Review checklist

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

[maxep]

This looks great!! very nice clean up and refactor as well 👏
I left a suggestion about naming.

[maxep]

Can we rename this to throttler instead of sampler? it can be confused with sampler we apply to session.

[ncreated]

Good point 👍. Renamed to "throttler" with accept(event:) API:

internal protocol RUMViewUpdatesThrottlerType {
    func accept(event: RUMViewEvent) -> Bool
}