Adopt utility process in terminal/pty host

[bpasero]

Follow up from #154050

We now have sufficient infrastructure in place to easily fork a UtilityProcess with support of message port communication to other processes:

vscode/src/vs/platform/utilityProcess/electron-main/utilityProcess.ts

Line 121 in ed6bb07

export class UtilityProcess extends Disposable {

Currently the PTY agent is still running as child process in the shared process housing all terminals:

vscode/src/vs/code/node/sharedProcess/sharedProcessMain.ts

Lines 386 to 399 in ed6bb07

	const ptyHostService = new PtyHostService({
	graceTime: LocalReconnectConstants.GraceTime,
	shortGraceTime: LocalReconnectConstants.ShortGraceTime,
	scrollback: configurationService.getValue<number>(TerminalSettingId.PersistentSessionScrollback) ?? 100
	},
	localize('ptyHost', "Pty Host"),
	configurationService,
	environmentService,
	logService,
	loggerService
	);
	ptyHostService.initialize();
	services.set(ILocalPtyService, this._register(ptyHostService));

We should consider moving the PTY agent out into a standalone utility process to reduce pressure on the shared process (and actually vice versa, reduce pressure on terminals).

[bpasero]

Here are some pointers how it works today with the shared process which I think is very similar to the PTY-Host, because:

• there is only 1 shared process (there is only 1 PTY-Host)
• every window connects to the shared process (and PTY-Host)
• to avoid startup perf issues, we want the process to spawn only on demand after editors have restored, triggered from the window [1]
• shared process and PTY-Host are leveraging bootstrap-fork to come alive as AMD module

1.) electron-sandbox: Workbench Shared process service

Any client in the workbench window that needs a channel to use a service from the shared process does so via the SharedProcessService. This service will:

• await the LifecyclePhase.Restored phase (here)
• use the acquirePort() utility method to ask the main process for a MessagePort exchange
• create a MessagePortClient with the result

The utility method acquirePort does all the heavy lifting of passing a MessagePort over from the main process through the preload script and into the sandboxed window. It expects the vscode:createSharedProcessMessageChannel to be listened on from the main process via Electron IPC mechanics. The main process will respond to the vscode:createSharedProcessMessageChannelResult. The sandbox blog post covers this in more detail.

👉 For the PTY-Host I would pretty much take the workbench shared process service code as is and rename it to PTY specifics. I am not sure if the service has to be so generic to return IChannel. This is more meant for a process that exposes many things, but if the PTY Host only exposes fixed set of methods, I would probably only expose those.
👉 If there is sufficient overlap, we can extract a common base class and reuse the code

2.) electron-main: Shared Process Starter

The SharedProcess in electron-main is the listener to the vscode:createSharedProcessMessageChannel Electron IPC request from any window and is responsible for spawning the process and exchanging message ports. This class will:

• spawn the UtilityProcess upon first workbench window connection with some payload and the AMD entryPoint
• calls UtilityProcess.connect() to obtain a MessagePort and send that back to the requesting window via the vscode:createSharedProcessMessageChannelResult Electron IPC channel

👉 you can ignore the workerXY methods, they are for when the deprecated hidden window is used
👉 For the PTY-Host I would again think that a lot of the code can be reused, so we can think about a common super type here

3.) node: Shared Process Main

The SharedProcessMain is the actual module that runs as utility process. This module will:

• listen to the payload to come in to instantiate itself
• send some lifecycle events back to the main process via postMessage to signal ready state
• create a IPCServer to accept MessagePort connections leveraging ipc.mp.ts helper
• exposes services as IChannel to the clients

👉 I think for the PTY-Host, you already do most of this, the only new thing is to check for the PTY-Host running from a utility process or a bare node.js process and then instantiating the right IPCServer and using the right methods for message communications. We provide a IPCServer for node.js as well via ipc.cp.ts

[1] Possible solution to that is covered in: #175959