Fix #4815 by adjusting length n before checking overflow

[minghuaw]

Motivation

This is to solve the issue #4815, which finds that the encoded bytes of a max-sized frame with a negative-valued length adjustment cannot be decoded with the codec.

Solution

The problem is caused by checking overflow before making length adjustment to the decoded length n (#4815 (comment)). This PR simply reverses the order (ie. it now makes adjustment to the length n before checking overflow).

A new unit test read_single_frame_negative_length_adjusted_and_max_sized has been added to tokio-util/tests/length_delimited.rs to test this scenario.

[Darksonn]

Looks good to me.

[minghuaw]

The failed tests seem like a "bug" with the h2 crate. (h2_connect_large_body test)

It uses a LengthDelimitedCodec in its own h2::codec::FramedRead but uses a custom encoder for its own h2::codec::FramedWrite. The LengthDelimitedCodec in the reader has a length adjustment of positive 9; however, the custom encoder doesn't make any length adjustment when it encodes the payload length (see encoder, head).

One workaround is to add a positive 9 when setting the h2::codec::FramedRead's max frame size

[Darksonn]

We might want to consider waiting until the next breaking release of tokio-util. We are not going to make a release that breaks hyper.

[Darksonn]

I'm closing this for now. I'll reopen it when we make the tokio-util breaking release.