Haxe server should not use --wait stdio

[ncannasse]

Communications on stdout/stdin are error prone for several reasons:

• a print left somewhere in the compiler will break the protocol
• a macro starting a command that prints things will break the protocol

I recommend moving to proper socket and drop the hack that makes haxe language server opens a proxy socket

[Gama11]

It still seems nice to have a proxy in case we need to restart the server (haxe.executable changed or similar).

[nadako]

Although I can agree on the second point (the first one is just a compiler bug), I won't change this unless there's a "non-hack" solution to address issues mentioned in HaxeFoundation/haxe#5188.

[frabbit]

I also experience problems in a big project which i think are related to this, will try to figure that out when i have more time.

[nadako]

So I was taking a bath and suddenly it occured to me that we can do the same trick as in the eval debugger:

• bind a free port and start listening on the IDE side
• start haxe server passing the port to connect to as an argument
• haxe connects to IDE and both proceed to do normal socket communication

[Gama11]

So finding a free port is the only blocker to not using --wait stdio? Your earlier comment sounded like it was more than that ("issues mentioned in HaxeFoundation/haxe#5188").

[nadako]

this should address all issues: free ports (just bind to 0) and knowing when connection can be/is established (Haxe will connect to us itself and then we're ready to communicate)

[nadako]

I started working on that, though I don't have a lot of free time nowadays.
On vshaxe side this requires some refactoring to properly abstract and separate the lowlevel haxe communication layer, so we can support both stdio and sockets.