Fix 648 url object not accepted and 650 dispatcher not respected

[berndfuhrmann]

Issue #, if available:
#648, #650
Description of changes:
There is a seperate PR for #648, see description there.
For #650 when fetch is instrumented, we check now if there is a dispatcher property settable on a request which is not transferred to the cloned request. It is a bug detector for undici. If that bug is detected, a work-around is enabled, which will search for the dispatcher symbol property and copy it manually to the new request. A test for that has been added.
In the future, this work-around can be removed, once the fix in undici is sufficiently available. For now, this should resolve @Kruspe problem.
Please note that the bug detection is only done when enableCapture is called, so only when the program initializes. This minimizes impacts to performance.
I included my fix to #648, since not doing that would make a difference in how the unit test works.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Kruspe]

I'd say this is unrelated to #650 and is rather a new issue to fix the support for Requests that have a dispatcher set directly.

#650 aims at fixing the behavior for the following calls to fetch:

fetch("https://something.com", {dispatcher: agent})

---

Not sure if we need this workaround or if we can wait until the undici fix is available. Seems like it's currently not used or we would have seen issues for this bug.

[berndfuhrmann]

@Kruspe
This is from a test I added: await activeFetch('https://www.foo.com', { dispatcher: agent});. Isn't that what you're talking about?

[Kruspe]

Ah I see what you mean. True the newly created Request would contain this and copying this over correctly would fix that issue.

Scenarios like this:

fetch(new Request("https://something.com"), {dispatcher: agent});

would still be broken though right?

In general I think it's a good idea to combine the options into the calls we pass to the original fetch as otherwise we would be losing those options.

[berndfuhrmann]

@Kruspe Thanks for pointing that out. Added a test and a fix.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.56%. Comparing base (3b89008) to head (26f5e6d).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #698   +/-   ##
=======================================
  Coverage   83.56%   83.56%           
=======================================
  Files          36       36           
  Lines        1813     1813           
=======================================
  Hits         1515     1515           
  Misses        298      298           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles