inspector: initial support for Network.loadNetworkResource

[islandryu]

Fixes: #57873

Adds initial support for Network.loadNetworkResource in the inspector.
https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-loadNetworkResource

how to load network resource

Resource fetching is done via a spawned child process to keep the inspector's event loop clean and isolated.
The JavaScript code for the fetch process is currently hardcoded, which may not be ideal, but I couldn't come up with a better approach at this point.

When --experimental-inspector-network-resource is set, a dedicated worker for loadNetworkResource is launched.
This worker fetches the resource and returns the result to the frontend.
https://github.com/nodejs/node/pull/58077/files#diff-5d3d58cbcfda008f49966a11d73863e67b78a237aa386f1fbdc5c9124136c1eb

check the behavior in chromium

To verify this change in Chromium, modify the section in the link as shown below and launch Chromium with the built DevTools frontend.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/core/sdk/Target.ts;l=87-88

      case Type.NODE:
        this.#capabilitiesMask = Capability.JS | Capability.NETWORK | Capability.TARGET | Capability.IO;

# open Chromium with built devtools-frontend
Chromium --custom-devtools-frontend=(file path)

other infomation

If this change is considered acceptable, I will send a follow-up change request to expand the Node.js DevTools target with IO support.
If it is necessary to wait until Network.loadNetworkResource becomes stable in CRDP, please feel free to keep this PR pending.

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/gyp

[codecov]

Codecov Report

Attention: Patch coverage is 78.86792% with 56 lines in your changes missing coverage. Please review.

Project coverage is 90.18%. Comparing base (de57d9b) to head (c2e62d3).

Files with missing lines	Patch %	Lines
...internal/inspector/load_network_resource_worker.js	27.27%	40 Missing ⚠️
src/inspector_agent.cc	82.97%	5 Missing and 3 partials ⚠️
src/inspector_js_api.cc	85.71%	1 Missing and 7 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #58077      +/-   ##
==========================================
- Coverage   90.19%   90.18%   -0.01%     
==========================================
  Files         635      639       +4     
  Lines      187344   187614     +270     
  Branches    36793    36813      +20     
==========================================
+ Hits       168974   169208     +234     
- Misses      11137    11139       +2     
- Partials     7233     7267      +34     

Files with missing lines	Coverage Δ
lib/internal/inspector/fall_through_handle.js	100.00% <100.00%> (ø)
lib/internal/modules/run_main.js	97.67% <100.00%> (+0.05%)	⬆️
src/inspector/io_agent.cc	100.00% <100.00%> (ø)
src/inspector/io_agent.h	100.00% <100.00%> (ø)
src/inspector/network_agent.cc	62.19% <100.00%> (+0.30%)	⬆️
src/inspector/worker_inspector.cc	96.29% <100.00%> (+0.46%)	⬆️
src/inspector/worker_inspector.h	100.00% <ø> (ø)
src/inspector_agent.h	100.00% <ø> (ø)
src/node_options.cc	85.29% <100.00%> (-0.10%)	⬇️
src/node_options.h	98.90% <100.00%> (+<0.01%)	⬆️
... and 3 more

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jasnell]

Nit... since we're finally up on c++20, we can start using the more condensed namespace node::inspector::protocol { syntax where appropriate.

[legendecas]

I am not a fan of spawning a Node.js process for each Network.loadNetworkResource request from devtools frontend. A devtool frontend may call this method multiple times simultaneously if there are several source maps and spawning a Node.js process for each of them seems superfluous and resource draining.

As an alternative, we could expose this as a hook to JS inspector API so that it will be properly covered by environment variables like HTTP_PROXY and the permission model. Additionally, this allows the JS API hook to filter which domain the process is allowed to send request to.

[islandryu]

If we hook into the JavaScript side, wouldn’t it end up running on the same event loop as the main script?
If the code breaks before the fetch process for loadNetworkResource completes, it could cause a problem where the resource can’t be fully retrieved.

That said, as you pointed out, spawning a new process every time would consume a lot of resources, which is also problematic.
So I’m considering other approaches that don’t interfere with the event loop.

[joyeecheung]

Maybe spawning a worker thread would be a good enough compromise for the moment?

[islandryu]

That sounds like a good.
I had excluded worker_thread from consideration because it also gets targeted by the debugger,
but I’ll add a flag to prevent it from being targeted by the debugger.

[legendecas]

This command is not used.

[islandryu]

@legendecas cc: @joyeecheung
I made changes to spawn a worker process for fetching.
It’s also possible to change it so that this behavior is delegated to the user via the Inspector JS API.
However, since the worker needs to be launched before the entry file is loaded in order to resolve source maps for Chrome DevTools, this part likely cannot be delegated to the user.