start hh_server if it's not already running
Summary:
We should spin up the hh_server if it's not already running.
Previously, this used to be handled by Nuclide which would always call "hh_client start" to start it if necessary before opening the persistent connection.
But that's not very LSPish. So instead we'll make the initialize method spin up the hh_server if necessary. And later in the stack we'll show progress reports, like "hh_client" does at the command-line. (but which "hh_client start" doesn't do).
LSP and VSCode expect a prompt response to "initialize". But we can only give a proper response to initialize after we've connected to a server (since that's when we know whether the server can offer us a persistent connection), and that might take a long time (if it has to typecheck or load state first).
So here's a compromise. We'll see if the server is ready promptly, within a few seconds, and if so then we can give a proper response to initialize. But if the server is still busy, then we'll just give a provisional response for now, and enter into a state where we reject incoming LSP requests while we're waiting for the server hello. Once that comes we'll try to establish a persistent connection. --> If we can't establish a persistent connection, then we'll CLOSE, so that when the client restarts us, then the server will be already ready, and we will be able to give a proper response to initialize at that time.
There's one catch. If the client sends us didOpen/didChange/didClose notifications before the "hello" has yet arrived, then we'll have to buffer them up and apply them all after the "hello" arrives.
IN ADDITION, this diff also rewrites the "connect_persistent" function to re-use as much connection code as possible from ClientConnect.
Reviewed By: arxanas
Differential Revision:
D5111134
fbshipit-source-id:
e1510fa6614eeb7d843298dcffcad2b2bbcb0c87