Use concrete errors

[jbr]

using a dynamic error like anyhow is ideally suited to application code, not library code. async-h1 can enumerate every type of error that can occur, and it should do so.

we may want to revise the details of error enum before 3.0, but this represents a first effort at removing http_types::Error from async-h1.

[yoshuawuyts]

Can you clarify how this is intended to deal with HTTP status codes? I like the way the code looks in async-h1, but I worry about the integration with Tide, since it appears this design requires manually matching the error kinds to their corresponding status codes. Whereas now the status codes are encoded into the error itself.

[jbr]

At the async-h1 level, status codes were always ignored previously. If an error occurs at the async-h1 level, there is no opportunity for tide to render a response. A few of these should have error handling inside of async-h1, but all async-h1 errors are irrecoverable from a higher framework perspective. The important point is that previous to this change, the only handling of async-h1 errors in tide was to log, as they are outside of the request-response cycle. After this change, a further PR will add selective error handling to async-h1 for any errors that make sense to return a response to, using match.

[jbr]

Merging this into the v3 branch