Resource events derived their start date from the report time (now - transferTime) at the moment the event was serialized on the RUM thread. Any latency between request completion and serialization shifted the resource start later, so client resource spans could appear to start after the upstream APM spans they parent.

Capture the wall-clock dispatch time in DdUrlTransfer when the request starts and carry it on the resource as startTime. RumViewScope and RumActionScope now prefer this explicit start time, falling back to the previous computation when it is absent.

What does this PR do?

Capture the wall clock time when the HTTP request starts, not when the request is serialized.

Motivation

When integrating our app's HTTP requests with tracing headers, we observed incorrect client request start times in flame graphs. The delta was very similar to behavior we observed with the Operations API that led to #160.

Additional Notes

See #172

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)