Sandbox: enable extension host communication

[bpasero]

This is the continuation of #123592

The extension host is no longer forked off the renderer but it still uses node.js for communication. We need a solution that scales for the amount of data that is coming in and going out between renderer and extension host. In other words, we should not send the data through the shared process message port.

This is similar to what the file watcher had to go through and I ended up pushing for a node.js enabled web worker solution, which means:

• the shared process creates node.js enabled web workers
• the web worker owns one part of the message port end point
• the web worker forks processes and proxies all communication via the message port to the receiver
• the other end of the message port is sent back to the renderer

I believe the extension host could use a similar model, provided that the runtime behaviour of a process from a node.js enabled web worker is identical to a process forked off a node.js enabled window. Maybe @deepak1556 could verify that assumption.

[deepak1556]

I believe the extension host could use a similar model, provided that the runtime behaviour of a process from a node.js enabled web worker is identical to a process forked off a node.js enabled window.

Yup they are similar, the underlying fork syscall just happens to be triggered on a different thread but the process information copied are all similar to that when being spawned in the current model of extension host, only the thread related information will be different but we are not interested in those data from the child process.

[bpasero]

In my opinion there are so many problems with fork(2) in multi-threaded programs that it's almost impossible to do it right.

🐙

[deepak1556]

Completed in #150753