config file for more flexible http server setup

[scottlamb]

Context: this comment on #132, #35 , #27, #31 .

It'd be nice to have more than a single --http-addr=ipaddr:port and allow them to differ in configuration (different --allow-unauthenticated-permissions, --trust-forward-hdrs, etc). I think it's cheap to have several hyper::Servers in the process. Eg, I'd like to run my server in the following configuration:

1. an http server to go behind my Internet-facing https proxy server. It requires authentication and trusts the X-Real-IP and X-Forwarded-For headers. (I probably should also a header from the proxy with a shared secret to avoid being insecure on accidental misconfiguration.)
2. http over a trusted Unix-domain socket for conveniently adding users/sessions from the CLI without having to shut down the server (as moonfire-nvr login expects now) or to have already created and stored session cookie.
3. a http server for use by Prometheus monitoring. I'd like it to be on a separate binding to avoid confusing it with the stuff that should be exposed to the Internet.

Another use: Bobberty just mentioned wanting an IPv4 binding + a IPv6 binding.

Per-bind address knobs might grow to include:

• bind address: IPv4, IPv6, or Unix domain
• systemd socket activation flag: expect the parent process to have already done the binding rather than doing it ourselves. Use the bind address (if any) to distinguish between multiple fds rather than for binding. [edit: better yet: use the socket name; see FileDescriptorName= and sd_listen_fds_with_names.]
• for Unix domain, a flag to allow SO_PEERCRED-based uid authentication rather just trusting the peer. (The user table has long had a unix_uid for this but it's unimplemented.)
• equivalent of --allow-unauthenticated-permissions
• equivalent of --trust-forward-hdrs, with the additional ability to configure a shared secret as mentioned above
• what to serve: just the normal interface (static files + API), just Prometheus metrics, or both.
• for https: letsencrypt challenge config or supplied certificate file paths.

Seems way too awkward to specify all the stuff above on the commandline, and I don't think it belongs well in the database (I don't want to add a configuration tool for it and folks are used to configuration files for stuff like this), so I think we should introduce a config file. toml, text proto, json, yaml, something like that.

[scottlamb]

The crux of this issue is done: there is a config file format with a [[binds]] section now that supports customizing some things. Not all the specific ideas mentioned here are implemented but I think the missing things are covered by other issues.

[scottlamb]

Oops, mentioned the wrong issue in that commit. Reopening this one.