feat(util): add ResponseExt trait

[joshka]

This adds a ResponseExt trait to the http_body_util crate. This
trait provides two methods, box_body and box_body_unsync, which
allow you to box the body of an http::Response to make writing code
that returns responses with different body types easier.

use bytes::Bytes;
use http::{Response, StatusCode};
use http_body_util::{Empty, Full, ResponseExt};

let response = match uri.path() {
    "/greeting" => greeting().box_body(),
    "/empty" => empty().box_body(),
    _ => not_found().box_body(),
}

fn greeting() -> Response<String> {
    Response::new("Hello, World!".to_string())
}

fn empty() -> Response<Empty<Bytes>> {
    Response::new(Empty::new())
}

fn not_found() -> Response<Full<Bytes>> {
    Response::builder()
        .status(StatusCode::NOT_FOUND)
        .body("Not Found".into())
        .unwrap()
}

[cratelyn]

for what it is worth, i've often done this using http::Response::map(), and the http_body_util::BodyExt::boxed() and http_body_util::BodyExt::boxed_unsync() methods, respectively.

so often, i'd expect the expression above to look like:

let response = match uri.path() {
    "/greeting" => greeting().map(BodyExt::boxed()),
    "/empty" => empty().map(BodyExt::boxed())
    _ => not_found().map(BodyExt::boxed())
}

i'm not strongly disposed for or against this myself, but thought i'd seed the conversation about the ergonomic benefits of this proposal with what the existing alternative would look like today.

[joshka]

i'm not strongly disposed for or against this myself, but thought i'd seed the conversation about the ergonomic benefits of this proposal with what the existing alternative would look like today.

Your solution was exactly what I wrote that was the impetus for this at https://github.com/TechEmpower/FrameworkBenchmarks/pull/9728/files#diff-3711f6ea37e3b6a98921c7b0e5f76c44ca34e1175fabf70ae02672d97ec15231

Yeah, this is purely ergonomic, but it makes sense because you might have many routes which leads to lots of repetition. There's a "Rule of three" rationale here - for your example with exactly 3 items, I wouldn't have bothered - but for more than that it seems like an obvious thing to want to simplify.