Expose raw request head bytes in Hyper Server and support using it in Hyper Client

[heiwais25]

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

This is a hard blocker to use Hyper as a proxy server without worrying about the unexpected normalization by Hyper.

We want to use Hyper as a proxy server in front of the existing services, which are very old. The old services have its own custom logic to support the requests even for non-RFC compliant requests to have backward compatibility. Using Hyper as a proxy has a potential problem since it has its own parsing and normalization logic, such as lower casing of the header name.

The best situation is that Hyper can capture the raw head bytes after parsing it and Hyper client supports it to encode it to bytes instead of using the normalized request. This helps us to avoid any issues in normalization since we will forward the raw bytes.

Describe the solution you'd like

1. Store the slice of the read_bytes after parsing the headers as a request extension
2. Hyper Client uses it in encoding headers if the extension is present

Describe alternatives you've considered

1. Implement the proxy from the scratch
   • This requires us to implement the most of the HTTP server functionality that Hyper already has.
2. Just use Hyper request
   • There is always risk that Hyper decode the request head bytes compared to the existing server

[seanmonstar]

Hey there! Yea, I've seen interest in this before. Let me grab together the current status.

At one point, we did exactly as this described for curl, or at least, half of it: putting Http1RawRequest in the extensions. But it turned out to not be as useful, so we removed it. There exists a PR to add that part back in, but it would need to be rebased: #3417

The second half is much more nuanced, that which of using the extension type for the bytes to write. I could perhaps be convinced otherwise, but it's a delicate matter. The concern I have is that of writing bytes that imply different semantics of the body than what hyper understands, and that confusion resulting in message splitting.

---

Another approach which is much safer would be the proposed extension types for "original header order" and "original header case" (see #2695). These types would simply define how hyper received the original bytes, and also how hyper should iterate and case the bytes. The blockers to those types so far has been coming up with a forwards-compatibly public API.