provide more context of opaque hyper errors

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

Hyper errors are opaque, in the sense that they can contain a lot of different things,
but except for a set of things you can test for, there is lot you cannot for.

However, hyper does make up for that, by providing clear error messages,
which honestly given a decent tracing setup is fine enough for issues
that you do perhaps want to prevent.

The problem however is that for plenty of issues it doesn't tell what it receives,
despite it having access to these values. Now I get that this might be to safe on resources,
given it does mean you now would need to store these somewhere somehow.
This is especially complicated as these errors can come from a pretty deep chain.
Which makes it even the more complex.

Still.. Not sure how else I would easily debug rare issues that perhaps are things
that indicate I really need to improve my setup, or if it's just a bogus client/server.

Describe the solution you'd like

When receiving errors (packed by https://docs.rs/hyper/latest/hyper/struct.Error.html)
such as invalid HTTP version parsed it would be great if it could also tell what it received,
e.g. invalid HTTP version parsed (HTTP/3), or something like that.
because for now I have a hyper 0.14 client running somewhere which gave this error,
and it would be great to know what that server responded back...
I'm guessing it's going to be HTTP/3, but how to know...

Describe alternatives you've considered

Only alternative I see is keep a bucket with such errors where I can store the full request/response
dump... But that seems a bit excessive.

Start with hyper::Error and the invalid HTTP version parsed error path, then trace where the received value becomes unavailable. Check how context could be retained through the deep error chain without an excessive request/response dump; done means relevant errors expose the received value, such as the HTTP version, with suitable behavior for resource use.