W3C implementation generates a new parentID for each request

Issue

As part of this PR: https://github.com/cloudfoundry/gorouter/pull/261

W3C support was added which is great! However it seems like the functionality was decided to make new parentIDs when you receive a new request. This doesn't seem like the correct behaviour for the gorouter since it is only proxying the request and is not a member of the trace. As far as I know, gorouter does not have support for reporting to OTEL or Zipkin tracers and only acts as a helpful proxy with this header support.

https://github.com/cloudfoundry/gorouter/pull/261/files#diff-4c0749740a74100927f204e1e56dfa5334d5a43ae2a57f3d6dfafccfa7c02897R135-R156

The effect of this is traces using W3C are always disconnected when routed through the gorouter because the next hop receives and records a child span that is not connected to any known parent spans.

Affected Versions

All since this PR was merged: https://github.com/cloudfoundry/gorouter/pull/261

Traffic Diagram

HAProxy ---> Gorouter ---> App ---> Gorouter ---> App

Steps to Reproduce

1. Have 2 endpoints with tracing
2. Have app1 call app2 through the gorouter
3. Notice in the trace report the spans are disconnected with the exception of being in the same trace

Expected result

ParentIDs should not be recreated, they should be transparently passed to the next hop.

Current result

ParentIDs are always recreated, disconnecting your spans from their children.

Possible Fix

See linked lines above. Next() should not be called or generate a new parentID. cc @tlwr not sure if you still help out with this project or if you could provide some rationale.

Start with the PR #261 diff linked in the issue, especially the referenced lines around Next() and W3C parentID handling. Trace the request path through the gorouter and verify with the two-endpoint reproduction that parent IDs pass through transparently and spans remain connected.