Access TurboVNC via a unix socket instead of a port

[consideRatio]

By exposing the TurboVNC vncserver with a unix socket file, created by jupyter-server-proxy with read/write permissions only for the current unix user, TurboVNC becomes suitable for example in the-littlest-jupyterhub deployments. The key difference is that multiple users can run their own VNC servers now without exposing it to other users, as a unix socket file compared to a TCP port, comes with user specific permissions.

Breaking change

This requires TurboVNC 3.1.0 and is due to this a breaking change worth highlighting in a major release.

From the 3.1 beta.1 changelog:

6. The TurboVNC Server can now listen on a Unix domain socket, rather than a
   TCP port, for connections from VNC viewers. This is useful in conjunction with
   SSH tunneling, and it also allows the Unix domain socket permissions to act as
   an authentication mechanism for a TurboVNC session. Two new Xvnc arguments,
   -rfbunixpath and -rfbunixmode, can be used to specify the Unix domain
   socket path and, optionally, the permissions. A new vncserver argument,
   -uds, causes the script to automatically choose an appropriate Unix domain
   socket path under the TurboVNC user directory. See the Xvnc and vncserver
   man pages for more details.

The options -rfbunixmode and -uds shouldn't be of relevance since we use a pre-created socket file by jupyter-server-proxy.

[github-actions]

👈 Launch a binder notebook on this branch for commit c3b2c9f

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit 9fad4eb

[manics]

Can you update the VNC server section of the README to say the vncserver must support UNIX sockets?

[consideRatio]

@manics thank you for the quick review! I rebased and added the commits abe5030 9fad4eb