Allow users to instantiate ServerSocket themselves

[alexarchambault]

This PR allows users to pass their own java.net.ServerSocket instance for domain sockets, rather than letting nailgun build it with its NGUnixDomainServerSocket and NGWin32NamedPipeServerSocket classes.

The should allow Bloop to get its ServerSocket instance via libdaemon-jvm, that

• can build those instances via JDK 16 native support for domain sockets, which should be more reliable than using JNA
• ensures such a server socket is created and listened on by only one process at a time, relying on file locks, among others, to do so.

(Feel free to either merge right now, or wait for the upcoming Bloop PR that relies on this.)

[alexarchambault]

cc @tgodzik

[tgodzik]

I think these changes look sensible, we should merge it (I think I should have the rights now, but you might need to make it ready to review)

btw. @alexarchambault do you think we could upstream the changes here to the main fork of nailgun? I haven't looked too much into this fork, but it would be awesome to get rid of it.

[alexarchambault]

@tgodzik Let's merge if it's fine then. Not sure if that's published once it's merged though, it seems there's no CI any more :/

[alexarchambault]

About upstreaming the changes here, I'm not really sure. It seems the changes revolve around:

• logging and some extra NGServer constructors (8f00594)
• more logging changes (ee3c434)
• disabling the security manager stuff (10c004d5) - discussed in Overhead of SecurityManager facebookarchive/nailgun#134 apparently
• plus the changes of this PR

[alexarchambault]

About the logging-related changes, I'm inclined to think these are unnecessary… Bloop could just configure java.util.logging on its own, rather than switching the codebase here to slf4j. If we really want logging messages via slf4j, we can always use a java-util-logging-to-slf4j bridge. But it seems Bloop disables those messages altogether via slf4j-nop, so we might as well just disable them by configuring java.util.logging (can even be done via some API calls IIRC).

[alexarchambault]

That leaves:

• extra NGServer constructors for custome stdin / stdout / stderr (no idea if that would be welcomed upstream)
• security manager stuff (maybe we could insist in Overhead of SecurityManager facebookarchive/nailgun#134)
• custom ServerSocket instance (this PR, no idea if that would be welcomed upstream either)

[tgodzik]

That leaves:

• extra NGServer constructors for custome stdin / stdout / stderr (no idea if that would be welcomed upstream)
• security manager stuff (maybe we could insist in Overhead of SecurityManager facebook/nailgun#134)
• custom ServerSocket instance (this PR, no idea if that would be welcomed upstream either)

From what I see the maintainers do not seem too active there, so maybe it's ok to leave this fork be.

[tgodzik]

For releasing I think it was done manually 🤔 I need to figure out who can be bothered to do it 😅