feat: add net module to utility process

[devm33]

Description of Change

Adds electron.net module to the utility-process. This enables making network calls from the utility process with the full capabilities of Chromium's native networking instead of the Node.js implementation. Example benefits include system TLS certificates, system proxy settings, support for basic, digest, NTLM, Kerberos, and negotiate authentication schemes.

The current net API in the main process requires any request from the utility process to be proxied via the main process UI thread. This PR makes it that main process establishes the URLLoaderFactory connection with the Network service and passes the remote endpoint to the utility process allowing it make requests directly with the Network service. This is borrowed on the same principle as renderer process perform today to make network requests.

Closes microsoft/vscode#192899
CC @deepak1556

Note: opening this with some remaining clean up work todo in order to get early feedback.

Remaining Completed clean up work:

• Add electron/utility module to docs-parser and typescript-definitions repos @devm33
  • feat: add utility process docs-parser#95
  • feat: add electron/utility module for utility process typescript-definitions#246
• Clean up imports once electron/utility module is available @deepak1556
• Implement fetch API for utility process without session hook @devm33
• Switch PID of loader_params->process_id to use utility process pid instead of kBrowserProcessId @devm33
• Move electron_api_net.cc from browser to common and rename linked binding @devm33
• Improve test coverage by reusing the common specs from api-net-spec.ts using a custom mocha runner for the utility process @devm33

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation, tutorials, templates and examples are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added net module to utility process.

[welcome]

💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[MarshallOfSound]

Haven't reviewed the content here but a question for folks with opinions @deepak1556 maybe.

I believe that shell/common is supposed to imply that code inside can run in any process, moving the net stuff into common would imply it would work in the renderer process which I don't think is correct 🤔 Thoughts on where this code should live?

[deepak1556]

I couldn't suggest a better home with the current directory structure, but maybe following options can also be considered

1. a component structure which allows sharing code between shell/browser and shell/services/node

  | components
    | net
      | js
        | net-client-request.ts
      | cpp
        | electron_url_loader.cc
        | electron_url_loader.h
      BUILD.gn
  | shell
     | browser
     | common
     | renderer
     | services
       | node
  | lib
    | browser
      | api
        | net.ts => depends on binding exposed from components/net and net-client-request.ts
    | common
    | renderer
    | utility
      | api
        | net.ts => depends on binding exposed from components/net and net-client-request.ts

2. Keep things simple and allow utility to reuse code from browser, we already do this for message ports.

[devm33]

Alright all of the planned follow items are completed here.

For PR description included and stakeholders cc'd, I'm not sure what groups or individuals should be cc'd. I think this requires API review, which looks like it's pending Semver Label Enforcement, but I'm not able to edit the labels here.

Any reviews or guidance through the process is much appreciated! 🙏

[dsanders11]

Some unrelated changed get pulled in to electron.d.ts due to the version bump of @electron/typescript-definitions. Perhaps that bump should land separately for a bit cleaner separation.

[devm33]

Some unrelated changed get pulled in to electron.d.ts due to the version bump of @electron/typescript-definitions. Perhaps that bump should land separately for a bit cleaner separation.

Sure thing @dsanders11, opened #40264
Thanks for adding the semver label here!

[devm33]

Some unrelated changed get pulled in to electron.d.ts due to the version bump of @electron/typescript-definitions. Perhaps that bump should land separately for a bit cleaner separation.

Sure thing @dsanders11, opened #40264 Thanks for adding the semver label here!

Oh it might be better left as part of this PR actually. Otherwise there are no utility process modules documented and the typescript definition generation fails.

[dsanders11]

Oh it might be better left as part of this PR actually. Otherwise there are no utility process modules documented and the typescript definition generation fails.

Can @electron/typescript-definitions be fixed so that it doesn't fail in that case? Otherwise we'll be blocked if we need to land a new version of that package before this PR lands, and it may take a bit of time given the large nature of this PR.

[devm33]

Can @electron/typescript-definitions be fixed so that it doesn't fail in that case? Otherwise we'll be blocked if we need to land a new version of that package before this PR lands, and it may take a bit of time given the large nature of this PR.

👍 On it!

[devm33]

Can @electron/typescript-definitions be fixed so that it doesn't fail in that case? Otherwise we'll be blocked if we need to land a new version of that package before this PR lands, and it may take a bit of time given the large nature of this PR.

@dsanders11 opened electron/typescript-definitions#247!

[zcbenz]

API LGTM

[jkleinsc]

API LGTM

[jkleinsc]

@devm33 looks like the newly added test is failing on linux: https://app.circleci.com/pipelines/github/electron/electron/76406/workflows/f315658a-de1f-4549-93c1-52080f4d7300/jobs/1637154

[deepak1556]

If there are no other concerns, I plan to merge this PR today and follow-up on the system network context usage for net apis.

[release-clerk]

Release Notes Persisted

Added net module to utility process.

[trop]

I have automatically backported this PR to "29-x-y", please check out #40890

[miniak]

/trop run backport-to 28-x-y

[trop]

The backport process for this PR has been manually initiated - sending your PR to 28-x-y!

[trop]

I have automatically backported this PR to "28-x-y", please check out #40967

[trop]

@miniak has manually backported this PR to "27-x-y", please check out #40968