Fallible services should be more explicit

In Hyper, all services that service HTTP requests are currently fallible with any error type that implements Into<Box<dyn Error + Send + Sync>>. However, accepting such a general type makes it prone to mistakes. Usually, servers want to avoid not sending a response, but it can be very easy to accidentally do so with this lax bound. In particular, it would be nice if we could model things like 404 responses as service errors in Axum, but that makes it really easy to accidentally create a service that aborts the connection on a single 404 instead of gracefully sending a response. Additionally, the bound requires that an error type be explicitly chosen for services that don't ever return an error (i.e. most of them), leading to an extra turbofish and Infallible.

Instead, I propose that Hyper only supports services that have AbortConnection as their error type. This type will either be a unit struct or wrap a BoxError. While it would still support services being able to abort the connection if they wish, it is now a lot harder to accidentally do so and requires explicit consent by the user.

The issue names no files, tests, or entry points. Start by locating Hyper's HTTP service error bounds and existing service interfaces, then trace how fallible and infallible services are represented. Done would require an agreed AbortConnection design, updated affected APIs, and tests covering graceful responses and explicit connection aborts.