Move to QUIC over HTTP

[ChillFish8]

As #59 mentions, currently, datacake supports no TLS options, as some of its desired applications have changed, it has become less useful to depend on hyper rather than using Quic and enabling TLS across all systems.

This in theory should improve some IO time and overheads in the existing RPC system in the real world.

Things needed:

• Must be able to provide a streamable request body.
• Must be able to send and receive header messages alongside a body stream.

[ousado]

I just had a look at libp2p and wondered whether it might be a good fit for datacake.
some interesting pros:

• (evolving) support for several transports, among them TCP, QUIC, WebSocket, WebTransport, IIUC behind a unified interface that offers stream multiplexing
• support for node discovery, NAT traversal, peer routing etc. which might be interesting for certain users/use cases
• very active development

Even assuming that libp2p-quic doesn't offer any immediate advantages over directly using one of the QUIC implementations for datacake itself, its use might get libp2p users interested and pull in new contributors that way. Especially datacake's default eventual consistency model strikes me as very appealing in that regard. All in all datacakes modularity and flexibility WRT storage backends and libp2p's modularity WRT transport options (and more) seem like a very good fit, at least at a first glance.

EDIT: Apparently libp2p's only support for private networking adds a second layer of encryption that requires a pre-shared secret key. Not very flexible.

[ousado]

quic-rpc is an interesting library:

• rpc system with explicit support for streams in none, one or both directions
• abstracts over different transports: TCP(using hyper), QUIC(using quinn) and an in-memory channel (using flume)
• typed
• serialization using serde, currently

might be worthwhile to look into

https://github.com/n0-computer/quic-rpc/