WebSockets and TLS

[marceline-cramer]

We want to support hosting Hearth in conjunction with existing web servers through a reverse proxy. This will let people host Hearth who don't have the ability to port forward but have an existing reverse proxy like Caddy or nginx set up. This will also integrate with other web services in a more Web-y way, which may be more friendly to typical internet users. Finally, web-like hosting makes it easy to access lots of individual Hearth servers running on the same server machine through human-readable URIs.

Using WebSockets as our networking transport seems to be the only reasonable way to accomplish all of this. We'd migrate away from our current TCP-based networking system with custom chacha- and OPAQUE-based security (#8) to WebSockets, and optionally, WebSockets Secure using TLS encryption.

Hearth servers using WebSockets will have URIs to connect to that look something like this:

wss://hearth.witchcraft.zone/

I don't think that the server should do any TLS connections. I think that TLS should be delegated to a dedicated reverse proxy system like Caddy. However, I think that the client should support both secured and unsecured WebSockets connections. Unsecure connections will be use for localhost connections and secure connections will be over a network. The client can use native SSL certificates. Unsure as to the details of that at the moment.

We're going to need to get rid of the hearth-network crate since it only contains TCP-based netcode that WebSockets will make obsolete. In its stead, we should either implement WebSockets support as a plugin crate (hearth-ws, hearth-websockets, or similar) containing both client-specific and server-specific networking code for the sake of modularity.