fix: ensure the span run-context for outgoing http requests does not spill into user code

[trentm]

This fixes the 'http' and 'https' instrumentation for outgoing requests
to not have the 'http' span context be active in user code. This ensures
that user code cannot create a child span of the http span, which would
(a) be misleading and (b) cause problems for coming exit span and
compressed span work.

Refs: #2430

Checklist

• Implement code
• Add tests
• Add CHANGELOG.asciidoc entry

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2021-11-30T23:01:16.106+0000

• Duration: 20 min 40 sec

• Commit: 9ca8dbb

Test stats 🧪

Test	Results
Failed	0
Passed	22
Skipped	0
Total	22

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• run module tests for <modules> : Run TAV tests for one or more modules, where <modules> can be either a comma separated list of modules (e.g. memcached,redis) or the string literal ALL to test all modules

• run benchmark tests : Run the benchmark test only.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[trentm]

The tests were failing on this (with some added console.log('XXX ...') to try to show what is going on):

% node  test/central-config-enabled.test.js
TAP version 13
# remote config enabled
XXX making proto.request in http-request
XXX making proto.request in http-request
XXX making proto.request in http-request
ok 1 mock apm-server got central config request
ok 2 agent conf for key transactionSampleRate was updated to expected value
ok 3 agent conf for key transactionMaxSpans was updated to expected value
ok 4 agent conf for key captureBody was updated to expected value
ok 5 agent conf for key transactionIgnoreUrls was updated to expected value
ok 6 agent conf for key logLevel was updated to expected value
# remote config enabled: receives comma delimited
XXX making proto.request in http-request
XXX instrumentation not yet started
/Users/trentm/el/apm-agent-nodejs6/lib/instrumentation/http-shared.js:172
      const spanRunContext = parentRunContext.enterSpan(span)
                                              ^

TypeError: Cannot read property 'enterSpan' of null
    at Object.request (/Users/trentm/el/apm-agent-nodejs6/lib/instrumentation/http-shared.js:172:47)
    at httpRequest (/Users/trentm/el/apm-agent-nodejs6/lib/http-request.js:117:21)
    at getMetadataGcp (/Users/trentm/el/apm-agent-nodejs6/lib/cloud-metadata/gcp.js:28:15)
    at /Users/trentm/el/apm-agent-nodejs6/lib/cloud-metadata/index.js:73:9
    at processTicksAndRejections (internal/process/task_queues.js:79:11)

The issue is that we are accidentally instrumenting the outgoing http request attempts being done for cloud metadata fetching... and doing so with the agent in a state here:

• the require-in-the-middle hook is active, but
• the Instrumentation has not started.
  This state is only possible when the Agent class is being re-used in the same process, which some test files like "test/central-config-enabled.test.js" are doing.

a fix

A possible fix is to tweak "lib/http-request.js" (as we already did for the elastic-apm-http-client in elastic/apm-nodejs-http-client#161) to get early references to http.request and https.request so that the agent doesn't instrument itself. This kills two birds with one stone: we will also no longer get the following occasional abortive attempts to instrument the cloud-metadata fetching:

[2021-11-25T00:29:20.480Z] DEBUG (elastic-apm-node): intercepted call to http.request {"id":null}
[2021-11-25T00:29:20.481Z] DEBUG (elastic-apm-node): no active transaction found - cannot build new span

[astorm]

👍 Approving.

I see here that we've taken steps to ensure the request methods used by the agent are uninstrumented functions.

I also see that we're binding a request's callback to the run context that was active when the request was made.

I see we're invoking the original request using a new run context created via the parent run context's enterSpan method.

Finally, in the response event handler, I see we're ensuring the response is bound to the parent's run context.