build(deps): bump node-fetch from 2.6.9 to 3.3.2

[dependabot]

Bumps node-fetch from 2.6.9 to 3.3.2.

Release notes

Sourced from node-fetch's releases.

v3.3.2

3.3.2 (2023-07-25)

Bug Fixes

• Remove the default connection close header. (#1736) (8b3320d), closes #1735 #1473

v3.3.1

3.3.1 (2023-03-11)

Bug Fixes

• release "Allow URL class object as an argument for fetch()" #1696 (#1716) (7b86e94)

v3.3.0

3.3.0 (2022-11-10)

Features

• add static Response.json (#1670) (55a4870)

v3.2.10

3.2.10 (2022-07-31)

Bug Fixes

• ReDoS referrer (#1611) (2880238)

v3.2.9

3.2.9 (2022-07-18)

Bug Fixes

• Headers: don't forward secure headers on protocol change (#1599) (e87b093)

v3.2.8

3.2.8 (2022-07-12)

Bug Fixes

• possibly flaky test (#1523) (11b7033)

... (truncated)

Commits

• 8b3320d fix: Remove the default connection close header. (#1736)
• 7b86e94 fix: release "Allow URL class object as an argument for fetch()" #1696 (#1716)
• 8ced5b9 docs: readme - non ESM example (#1707)
• 71e376b ci(release): use latest Node LTS (#1697)
• e093030 Allow URL class object as an argument for fetch() (#1696)
• 55a4870 feat: add static Response.json (#1670)
• c071406 (1138) - Fixed HTTPResponseError with correct constructor and usage (#1666)
• 6f72caa docs: fix missing comma in example (#1623)
• 2880238 fix: ReDoS referrer (#1611)
• e87b093 fix(Headers): don't forward secure headers on protocol change (#1599)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dependabot[bot]
Once this PR has been reviewed and has the lgtm label, please assign davidgamero for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mstruebing]

This will require some rework, it's a major bump of node-fetch.

[brendandburns]

Presumably we need to do this in the upstream code generator anyway.

[cjihrig]

Here is the node-fetch v3 upgrade guide: https://github.com/node-fetch/node-fetch/blob/main/docs/v3-UPGRADE-GUIDE.md

There are some things that are relevant to us:

• The response.body is now nullable. That is causing most of the TypeScript errors here. I think we are safe to use response.body! in the few problematic places here though.
• Response.statusText no longer sets a default message derived from the HTTP status code. For us, this impacts the should handle error from request stream test because the 'Internal Server Error' message is no longer present.
• The timeout option was removed. This one might be trickier for us. We already have Reintroduce timeout and keep-alive for watch requests to match client-go #2131 in progress to restore keep-alive behavior, but that PR also sets requestInit.timeout, which I believe will not be valid.

Here are the current test failures with this PR and the TypeScript problems fixed:

  1) KubeConfig
       applytoFetchOptions
         should apply cert configs:
     /Users/cjihrig/programming/javascript/src/config_test.ts:272
            expect(requestInit.timeout).to.equal(5);
                                           ^

AssertionError: expected undefined to equal 5
      at Context.<anonymous> (src/config_test.ts:272:44)

  2) Watch
       should handle error from request stream:

      /Users/cjihrig/programming/javascript/src/watch_test.ts:70
        expect(doneErr.toString()).to.equal('Error: Internal Server Error');
                                      ^

AssertionError: expected 'Error' to equal 'Error: Internal Server Error'
      + expected - actual

      -Error
      +Error: Internal Server Error
      
      at Context.<anonymous> (src/watch_test.ts:70:39)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

  3) Watch
       should not call watch done callback more than once:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/cjihrig/programming/javascript/src/watch_test.ts)
      at listOnTimeout (node:internal/timers:564:17)
      at process.processTimers (node:internal/timers:507:7)

  4) Watch
       should handle server errors correctly:
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/cjihrig/programming/javascript/src/watch_test.ts)
      at listOnTimeout (node:internal/timers:564:17)
      at process.processTimers (node:internal/timers:507:7)

EDIT: The last two failures appear to be related to node-fetch v3 (unsure if it is a bug or intentional due to a spec change). Note the difference in this handler between v2 and v3. In those failing tests, the request is intentionally aborted, which triggers that 'error' handler. In v2, that would destroy the body stream. Without that happening, there doesn't appear to be a way for us to trigger the doneCallOnce function in watch.ts.