Feature: enable processing of RUM transactions, spans, and errors as a unit

[axw]

When the server receives events from agents, they are treated as a stream of independent events. This is really the only sensible thing to do for backend agents, as they are not guaranteed to send transactions, and related spans and errors in the same request.

For RUM, we are guaranteed that spans and errors will always be sent in the same request as their transaction. (@jahtalab @vigneshshanmugam correct me if I'm wrong)
Moreover in the RUMv3 protocol, spans are nested in their corresponding transaction; we split them apart.

For RUM only: if we maintained the relationship between spans, errors, and their parent transaction, then we could apply more intelligent processing of these events. For example, the server could:

• aggregate span metrics for each transaction (recording them on the transaction doc), such as statistics about long tasks that occurred within a page-load (RUM: Add longtask to experience field on transaction schema #4226)
• adjust timestamps of all events within a transaction, based on the transaction duration (RUM timestamp is inconsistent with other agent timestamps #1830)

Note that any such processing would have to occur before tail-sampling. Once events are persisted to local storage, it would be too inefficient to restore the relationship information.

[hmdhk]

@axw , thanks for creating the issue. One correction is that only transactions and spans are guaranteed to be sent in one requests, errors might be send separately (depending on timing).

Generally I think it's a good idea to have some processing on the server side, although I think we should decide these on a case by case basis. e.g. going over all spans to aggregate longtasks might be too inefficient, while the agent has more efficient ways to aggregate these (I leave the performance side of it to you). In any case it's good to know if such processing is a possibility going forward.

[axw]

I don't think we'll be implementing this any time soon. For adjusting timestamps, we should consider implementing the solution we can up with for iOS (#5173) in the RUM agent. For aggregation, we can take a similar approach to what's described in #5936.