Now that we have a working HTTP API prototype, it's time to resurrect "service https" that has been removed from the nightly build along with the corpse of the old GUI.
Some considerations:
- nginx-based, obviously. That's the default HTTP server now.
- HTTP applications such as API and GUI must be explicitly enabled, by default just display a static info page
- user-supplied cert support would be cool, but intermediate certs may make it complicated
- support for custom proxy rules would be nice
A draft of what we need right now:
```
service https
# global options
listen-address <IPv4|IPv6|any> (multi)
# applications
api
port <port number>
debug <valueless>
keys
id <txt>
key <txt>
```
There's also a bit of a chicken and egg problem: API and in the future the GUI are HTTP servers on their own, but they also need the HTTP proxy. So we likely need separate scripts for configuring the proxy, and one script per API/GUI/etc.
The proxy configuration script can look into the subtrees to see what port to proxy requests too etc.
We need to find out if making the proxy script the "owner" of "service https" and making the API script the owner of "service https api" is sufficient to achieve that, or we need to do some trickery to make sure when you change "service https api port" for example, both scripts are triggered.