Add Unix socket listener support

[apeschar]

Allow listen to accept an absolute Unix-domain socket path in addition to an IPv4 or IPv6 socket address.

This adds a shared listener/stream abstraction while preserving the existing HTTP request handling, authentication, and TCP behavior. It also documents the new configuration and adds an end-to-end Unix socket test.

Example:

listen = "/run/snare.sock";

Unix socket paths must not already exist when snare starts.

Tests:

• cargo test --all-features
• cargo clippy --bin snare --all-features -- -D warnings

[ltratt]

Dumb question: what's the use case for listening on a Unix socket vs. a TCP/HTTP socket?

[apeschar]

Dumb question: what's the use case for listening on a Unix socket vs. a TCP/HTTP socket?

I generally prefer to host internal services on Unix sockets.

• Unix socket paths are more legible than port numbers. /run/snare.sock vs 18239. You don't have to worry about port conflicts.
• You can manage multiple configs (eg, for multiple users) without having to allocate port numbers. You can just listen on ~/run/snare.sock, let's say.
• You can control permissions granularly, eg, only allow nginx to connect instead of every user on the host. Unix sockets follow filesystem permissions. Otherwise restricting local connections requires complicated iptables rules.

[ltratt]

Most OSs can restrict TCP sockets to a given user. That said, I am inclined to see this as a useful feature. Integrating it sensibly might take a bit of finessing. For example, listen no longer has an unambiguous syntax. A first thought is that socket paths would be of the form unix:/path/to/sock and TCP sockets would -- for backwards compatibility -- be either IP:port or tcp:IP:port. [One day we could deprecate the non tcp prefix.] Warning: I haven't thought this through very carefully yet.

[apeschar]

listen = IP:PORT and listen = unix:/path/to/socket syntax would match Nginx. I think that's an intuitive approach.

I've updated the PR accordingly.