Large queue bug

[georgecrawford]

Describe your changes

https://financialtimes.atlassian.net/browse/DATA-10316 and the accompanying Slack thread describe a very old workaround in o-tracking to avoid a 'queue bug', whereby if more than 200 events are in the local storage queue (i.e. because the device has been offline or unable to send events for some reason), they are summarised in a single o-tracking:queue-bug event. This was presumably to avoid an enormous flood of events due to a buggy release of o-tracking many years ago. Importantly, summarising these events rather than sending them properly means the Spoor pipeline is missing key BI events in a significant volume (e.g. 2.6mn page:view events for FT App in a 90-day period).

However, the current implementation throws away some useful data, which will be required in order to assess whether the bug still exists or if these queued events can now all be sent safely.

This PR makes a few changes:

• removes add() and run() from the send.js API: these events were only used in unit tests, and should be preserved as internal helper methods only
• while assembling the o-tracking:queue-bug payload, if the queued events contain an older o-tracking:queue-bug event, merge the data in to the current context (rather than throw away the data from any events prior to the last 200)
• add additional context properties to the o-tracking:queue-bug: isOfflineCounts (how many of the events were sent with is_offline: true), maxOfflineLag and averageOfflineLag.

Additional context

JIRA ticket
DATA-10316

Checklist before requesting a review

• I have applied percy label for o-[COMPONENT] or chromatic label for o3-[COMPONENT] on my PR before merging and after review. Find more details in CONTRIBUTING.md
• If it is a new feature, I have added thorough tests.
• I have updated relevant docs.
• I have updated relevant env variables in Doppler.