Feature: Consider splitting the protocol implementation into its own crate

Is your feature request related to a problem? Please describe.

Hyper is one of my favorite Rust crates; however, there is an issue that I have with it that I probably should have brought up earlier in the 1.0 release process. While it is a fantastic crate with a rock-solid HTTP implementation, the only issue is that, in order to access this HTTP implementation, you need to use the API that Hyper provides.

It would be nice if there were a separate crate, to the turn of hyper-protocol, that would allow access to the protocol bits. This would allow other users to use this crate to build alternate APIs on top of the hyper protocol implementation.

Describe the solution you'd like

There would be a hyper-protocol crate that would provide an API without any I/O involved. This means that there is no async, no blocking, no Read or Write; just functions/structures that write to or read from in-memory buffers. hyper itself would then build atop this API to provide its current API.

This approach would have a number of advantages:

• The resulting crates would be more simple to test. Since you're testing the protocol and not the I/O bits, the branch space will shrink significantly, allowing test coverage to cover a larger number of areas.
• Without the I/O bits, it's easier to reason about the protocol code and ensure that it is correct.
• The HTTP protocol implementation can be reused by other crates. For instance, crates like ureq and hring provide their own HTTP implementations. To reduce the amount of work done by the open-source community as a whole, it would be nice to have them all use only one HTTP implementation.

See this website for more information.

Describe alternatives you've considered

While there's nothing wrong with the status quo, it's just that this means that other crates have to provide their own HTTP implementations. Reducing the number of other implementations would reduce the amount of work the Rust community needs to do.

Additional context

See this website for more information on the sans-I/O idea as a whole. It applies mostly to Python but I think that it also makes sense for Rust.

For a success story, see the x11rb-protocol crate, which I recently helped split out from x11rb. This allows for x11rb to use sync code and my own crate, breadx to use async code which reducing work by being based on the same X11 protocol implementation.

I am definitely willing to help out with this issue.

No files, tests, or entry points are named. Start by mapping Hyper's current protocol and I/O boundaries, then define the separate crate's sans-I/O API and determine what changes are required for Hyper to build on it; done means the protocol implementation is reusable without async or blocking I/O.