the agent is sometimes setting the 'traceparent' header on requests to APM server

[trentm]

Describe the bug

Gil observed in the edge dev setup of opbeans that there were requests from the Node.js APM agent to apm-server's intake API that included the traceparent headers, for example:

This makes the real transaction(s) with that trace id (in this case the opbeans-node requests) look like this apm-server intake API call is part of its distributed trace, which is bogus.

To Reproduce

Don't have a repro yet. For this to happen the agent would have had to have successfully created a span here: https://github.com/elastic/apm-agent-nodejs/blob/v3.12.1/lib/instrumentation/http-shared.js#L135
The theory is that the APM agent's request to apm-server happened in the context of a user transaction, and it piggybacked on that transaction, creating a span.

Ultimately, I believe, this code results in that span not being fully captured and sent. However the code adding the 'traceparent' header is above that.

Expected behavior

Requests to APM server should not get the 'traceparent' or 'tracestate' headers assigned.
Backing up a bit, an appropriate fix might be to see if we can ensure we don't get instrumentation interception of any of the APM agent's internal workings. This would avoid some log output confusion for users from this that appears for every request to APM server:

no active transaction found - cannot build new span
intercepted call to http.get { id: null }

Environment (please complete the following information)

• OS: Linux (edge oblt dev setup)
• Node.js and Agent version (from user-agent): elasticapm-node/3.10.0 elastic-apm-http-client/9.4.2 node/14.16.0
• APM Server version: a recent 8.0.0