OTel http instrumentation confuses NextTracerImpl

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Volta error: Could not find executable "pnpm"

Use `volta install` to add a package to your toolchain (see `volta help install` for more info).
Error details written to /Users/rudi/.volta/log/volta-error-2023-06-13_14_18_08.023.log

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000
    Binaries:
      Node: 20.3.0
      npm: 9.6.7
      Yarn: 3.6.0-git.20230603.hash-3c8237cb
      pnpm: N/A
    Relevant packages:
      next: 13.4.6-canary.0
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5

warn  - Latest canary version not detected, detected: "13.4.6-canary.0", newest: "13.4.6-canary.1".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/valkum/next-js-repro/tree/header-extraction

To Reproduce

1. Add instrumentation.ts with custom OTel setup
2. Make sure to setup the HttpInstrumentation
3. Start a local OTel collector with UI (e.g. Jaeger all in one).
4. Set env var export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
5. Build and start the repro app
6. Reported traces are not helpful

Describe the Bug

Similar to #51231 two traces are generated. One has the correct trace parent the other one not.

Tester is a simple binary which will create a traceId and inject the trace context per spec into the HTTP request to next.js

I create a gist with the two traces: https://gist.github.com/valkum/ee371bca6ad63b56fffceb16f729db24 in JSON form.

Expected Behavior

Only one trace should be generated. The remote context should be properly propagated.
The service root span should have the same arguments as the BaseServer::handleRequest span.

As next.js manages it's own rootSpan per the docs, and has some special handling in NextTracerImpl it makes sense to implement the header extraction for the trace context inside next.js as well and dump the HttpInstrumentation for next.js.
As spans are currently only generated in the renderWorker, extracting the headers at the top of the renderWorker HTTP request function call chain would be good, I believe. This way we would benefit from the trace context even with NEXT_OTEL_VERBOSE=1

Note: the spanId generation also needs to be fixed, else there would be two spans with spanId = 0

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

next start

Start with the header-extraction repro on the header-extraction branch and compare its two traces with the supplied gist. Read NextTracerImpl, BaseServer::handleRequest, and the renderWorker HTTP request path, including the instrumentation.ts setup. Done means one trace with propagated remote context, matching service-root and handleRequest span arguments, and nonzero span IDs.