Draft: Bug 40679: Missing features on first-time launch in esr91

Ok this MR is a doozey, sorry!

The bulk of the changes are in tor-control-port.js and essentially rebase the previous interconnected callback-spiderweb async socket implementation into a top-down async/await implementation. We now have two friendly objects with a clear API: AsyncSocket and ControlSocket.

AsyncSocket encapsulates an underlying socket transports and exposes the read and write functionality via async functions. Said functions properly throw/reject in the event of an IO error.

ControlSocket has an AsyncSocket and it implements the input read pump on the underlying socket which batches together multiple response lines into 'messages' which are routed to the appropriate commands. Commands are sent via the async sendCommand method which return messages on completion, or throws/rejects on error. In the event of an IO error in the underlying AsyncSocket object, all of the in-flight commands are now properly rejected and exceptions are thrown from their call sites.

Higher up the chain, the exported function controller is now async. If a control port connection cannot be made (if the daemon has not launched yet, for example) an exception is now thrown.

I have also added a new wait_for_controller function to be used from torbutton code which implicitly expects the tor-daemon to exist when it is run. This async function only resolves once the tor daemon has launched, so it is (should be?) always safe to call (assuming the tor daemon does eventually run).

NOTE: tor-launcher still calls controller as it is in charge of alerting the rest of the system that the tor daemon is ready by the "TorProcessIsReady" observer notification. Nothing else should ever call controller directly unless it is guaranteed that tor daemon is running.

• fixes tor-browser#40679 (closed)
• fixes tor-browser#40752 (closed)