refactor(http/retry): PeekTrailersBody<B> only peeks empty bodies

[cratelyn]

this commit makes a small, subtle change to the PeekTrailersBody<B> http response body middleware.

to help facilitate upgrading to http-body 1.x, we remove some tricky logic that involves Body interfaces that no longer exist after the 0.4 release.

currently, a PeekTrailersBody<B> is not fully consistent about the conditions in which it will peek the trailers of a response body: the inner body is allowed to yield either (a) zero DATA frames, in which case the body will be .await'ed and polled until the trailers are obtained, or (b) one DATA frame, so long as the inner body immediately yields a trailer.

meanwhile, the documentation comment for the type claims:

An HTTP body that allows inspecting the body's trailers, if a
TRAILERS frame was the first frame after the initial headers frame.

we won't have distinct data() and trailers() interfaces in the 1.0 release. we have a single BodyExt::frame() method.

consequently, porting this middleware as-is would be somewhat difficult. we might have to hold two frames, should we receive one frame, now_or_never() the second frame, and discover that we've been provided a second data frame rather than the trailers.

this all runs slightly against the invariants of Body, see this comment originally added in 7f817b5:

// Peek to see if there's immediately a trailers frame, and grab
// it if so. Otherwise, bail.
// XXX(eliza): the documentation for the `http::Body` trait says
// that `poll_trailers` should only be called after `poll_data`
// returns `None`...but, in practice, I'm fairly sure that this just
// means that it *will not return `Ready`* until there are no data
// frames left, which is fine for us here, because we `now_or_never`
// it.

this isn't quite true, as Trailers is just a wrapper calling poll_trailers:
https://docs.rs/http-body/0.4.6/src/http_body/next.rs.html#28-30

so, let's remove this. doing so will make the task of porting this middleware to http-body 1.0 in the short term, and additionally prevents any potential future misbehavior due to inner bodies not handling this eager trailer polling gracefully.

see linkerd/linkerd2#8733.

see #3504.

[cratelyn]

in conversation with @olix0r today i've gleaned some wisdom that the existing behavior, permitting one DATA frame so long as trailers are immediately available thereafter, is an intentional optimization to account for unary gRPC responses.

in that case, this change may not be the right course of action.

[cratelyn]

upon further reflection, i am going to close this. now knowing the implicit background of why we invoke now_or_never() here, i have some ideas about how to proceed. thanks for the insight! 💭 💡