Update fetch instrumentation to be runtime agnostic

[drewcorlin1]

Which problem is this PR solving?

This PR addresses #3413, but updating the experimental fetch instrumentation to not depend on browser specific constructs (window, location).

The motivation for this change is so I can instrument my NodeJS applications using fetch() with the @opentelemetry/instrumentation-fetch package.

My take is that this is much more of a bandaid than a true fix, as the fetch instrumentation still depends on the opentelemetry-sdk-trace-web, but it provides significant value in that I can use the instrumentation out of the box with no workarounds (like patching the global object globalThis.location = {}). I think the proper fix is to move some of the logic in opentelemetry-sdk-trace-web to opentelemetry-sdk-trace-base, but I am very new to this codebase and wanted to hold off on a larger refactor, in the interest of being able to contribute a targeted fix as quickly as possible.

Fixes # (issue)

Short description of the changes

Check for the existence of browser-specific constructs before referencing them, if they are not present return undefined/don't evaluate the expression.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I have run the tests and linting steps, and also tested this locally in a NodeJS application (fastify server that uses fetch).

My steps to test locally

• For both experimental/packages/opentelemetry-instrumentation-fetch and packages/opentelemetry-sdk-trace-web
• cd into that directory
• Build the package npm run compile
• Package it npm pack
• Install that tarball in my application npm i ../../Desktop/opentelemetry-js/<path to tarball>.tgz
• Run the application and jaeger locally
• Cause it to make a fetch call
• See spans show up from the fetch instrumentation

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: drewcorlin1 (e229969, d24e132, 4795cda, bc180bb, 46f1c10, 850897c, 15ca47f, 778dfac, 31fa4fc, b81bed4, fface3c)
• ✅ login: pichlermarc / name: Marc Pichler (421f01e)

[drewcorlin1]

Working on getting the CLA set up for my organization now

[drewcorlin1]

Ah I had only run npm run test, not all the other test suites. I see those failures locally now and will start addressing them

[drewcorlin1]

I've updated this PR to be a much smaller fix, avoiding any refactor. I've updated the description accordingly.

[codecov]

Codecov Report

Merging #4063 (777d51b) into main (10f6c46) will increase coverage by 0.02%.
The diff coverage is 100.00%.

❗ Current head 777d51b differs from pull request most recent head 421f01e. Consider uploading reports for the commit 421f01e to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4063      +/-   ##
==========================================
+ Coverage   92.31%   92.33%   +0.02%     
==========================================
  Files         330      329       -1     
  Lines        9421     9382      -39     
  Branches     1996     1985      -11     
==========================================
- Hits         8697     8663      -34     
+ Misses        724      719       -5     

Files	Coverage Δ
...s/opentelemetry-instrumentation-fetch/src/fetch.ts	96.53% <100.00%> (+0.02%)	⬆️
packages/opentelemetry-sdk-trace-web/src/utils.ts	93.67% <100.00%> (+0.07%)	⬆️

... and 2 files with indirect coverage changes

[pckilgore]

This seems much saner (especially in the short term) than monkey patching globalThis, which is what I'm currently doing to get fetch telemetry!

[diogotorres97]

@pckilgore @drewcorlin1 @pichlermarc any news on this?

[drewcorlin1]

@diogotorres97 just waiting for a codeowner to review

[pichlermarc]

LGTM % changelog text; I think this looks like a good step forward. 🙂 Thank you for working on this.

A side note: as you mentioned I also think some of the code needs to probably be moved in a follow up. We've recently started working on SDK 2.0 over at the next branch, so now is a good time to get breaking changes in if they're required. If you have specific action-items in mind, please open an issue so that we can plan it accordingly. 🙂

If the change requires breaking a stable interface, please tag @open-telemetry/javascript-approvers on the issue and state that it is a breaking change that should be considered for 2.0, we'll then review the proposal and add it to the scope for 2.0 if it is accepted.

[drewcorlin1]

@pichlermarc could you merge whenever you get a chance?