This fixes #26.

...because nitriding is no longer (just) a package.

Nitriding is going to be running two Web servers: one is public-facing
and meant to be accessed by clients and the other is enclave-facing and
meant to be accessed by the enclave application.

Nitriding is now a stand-alone application, obviating the need for an
API to add HTTP handlers.

The reverse proxy terminates TLS and forwards all but a select few HTTP
requests to the enclave application, which runs its own Web server.
Since the reverse proxy terminates TLS, the enclave application does not
need to bother with certificates and can expose a simple HTTP server.

Non-HTTP enclave applications need a way to link their key material to
the attestation document, which serves as our root of trust.  This
commit adds a new enclave-internal endpoint that allows applications to
register a hash over their public key material.  This hash (along with
a hash over nitriding's HTTPS certificate) is then embedded in
attestation documents.

This enclave-internal HTTP handler allows applications to signal their
readiness to nitriding.  When the handler is called, nitriding starts
its Internet-facing Web server.

Domain sockets are great for high-throughput applications but we don't
need troughput here; we need ease of use.

A simple Python client that retrieves its IP address by connecting to a
Web server.

The endpoint takes as input a SHA-256 hash, so "hash" better reflects
what's going on behind the scenes; "key" is too broad of a term.

This patch makes use of Let's Encrypt's tls-alpn-01 challenge which
is simpler than the http-01 challenge because it does not require a
separate listener on port 80.

...and add a -f to rm, while we're at it.

There's no real need for cmddeps.

...to make the array distinct from the default, which is all 0-bytes.

So far, nitriding has used DHCP to obtain an IP address, which adds
complexity and unnecessary attack surface.  This commit replaces our use
of DHCP with a hard-coded IP address.

This commit wraps up the configuration of the tap0 interface.  We
configure the interface statically to avoid having to use an in-enclave
DHCP client -- an unnecessary security risk.

Cheers to Ralph for pointing out the lack of explanation.

Least significant bit of the most significant byte indicates a multicast
address if set.

...otherwise, the operation fails.

This commit removes the chi import that's not part of its v5 API.  It
also initializes chi's middleware before we create routes because chi
requires that.

This commit 1) ensures that all required command line arguments are
present and 2) validates the arguments' values.  This commit also
changes the type of some configuration variables to more appropriate
types, e.g., uint16 for AF_INET port numbers.

This is going to facilitate the transition to a different hash function.

This adds clarity.

There's no reason to allow negative ports and Go's spec guarantees that
a uint is at least 32 bits -- the size of an AF_VSOCK port.

Ralph measured that this saves around 20 MB of space.

Note that we have to run `go get gvisor.dev/gvisor/runsc@go` in addition
to `go get -u` because we need gvisor/runsc's Go branch:
https://github.com/google/gvisor#using-go-get