lost server part 5 - failed init goes to lost state

lost server part 5 - failed init goes to lost state

Summary:
Previously we had two separate ways to indicate a failed connection:

(1) if failure happened within 3 seconds of an LSP initialization request then we returned a failure response in the conventional LSP manner so the LSP client could invite the user to retry initialization;

(2) if failure happened later than that during initialization, or if it happened at any time even after initialization had failed, then we entered a "lost_server" state and indicated to the user that they needed to restart.

I think that doesn't make sense for our connection to a persistent singleton server. It's much cleaner if we say that LSP initialization always succeeds (and we opt entirely out of the LSP "failure/retry during initialization" cycle). Instead, we ourselves will manage our connection to the server, and we'll use just a single means to indicate failure to the user. So these are the states:

* Pre_init: the client hasn't yet sent initialize
* In_init: the client send initialize, and we responded, and we're about to try establish a connection to hh_server
* Main_loop: we did establish a connection\!
* Lost_server: either we failed to establish a connection, or we did establish a connection but it was subsequently lost.

Reviewed By: alexchow

Differential Revision: D5620642

fbshipit-source-id: f1cccc67224ecc949f2e1c44e19255450ff21706