Improving automated remote connection via Inspector Protcol

Start by reviewing the Inspector API entry point and the existing node inspect workflow, then compare them with the proposed RemoteSession and shortcut-command approaches. The issue is ready for implementation only after the project chooses one concrete interface for non-interactive remote profiling that meets the listed enterprise constraints.

The Inspector Protocol allow us to use tools like V8 CPU Profiler and Heap Snapshots without relying on C++ binding. It also allows us to call those tools remotely, which is useful when running those tools in production via an automated workflow. We can connect to the Inspector Protocol remotely using the following methods:

1. node inspect host:port will open a REPL for users to run inspector commands
2. Chrome DevTools, ndb, etc. will provide a nice UI
3. Connecting via pure WebSockets (for example, via websocat or ws)

1 is not useful for automation, because it doesn't allow users to run scripts (it only works interactively). 2 has similar problems (since those are GUI), plus they also enable the Debugger domain by default, which is not desirable in production. 3 is the best option for automation, but it requires extra environment setup (installing websocat, ws. etc) which is not always possible during an outage, for example.

I would like to propose an alternative: in core, provide a simple way to interact with the inspector protocol on a remote process with automation scripts. Some implementation examples would be:

1. Allow users to run scripts on node inspect instead of opening a REPL
2. Allow users to connect to a remote host via the Inspector API (either via a connectToRemoteHost method or with a new RemoteSession class)
3. Via shortcut commands for the tools, which could be run against a remote process. For example: node diagnostics --cpu-profile --pid $(pgrep node)

Personally, I think the 2 option would be the most flexible and useful for our users, but I want to hear what other members of the WG thing.

Overall, I'm trying to ensure we can trigger those tools given the following constraints (which are common in enterprise environment):

1. No need to make changes to the application code (as changes can take days, weeks or months to propagate, depending on the company)
2. No need to install extra dependencies on the fly (companies can have strict rules against mutating the server, or installing dependencies can be forbidden by security until those dependencies are cleared as safe)
3. Trigger the tools on an already running process, without the need to stop it
4. Trigger the tool non-interactively / without intervention from a human (users should be able to trigger it from a bash script, for example).