Check HTTP/2 response bodies against the content-length header

[ericmj]

The content-length header of an HTTP/2 response was never compared with the DATA frames, so a body that was cut short, or that kept going past the declared length, was delivered as a complete response. Non-numeric and conflicting values were passed through as well.

Each stream now records the request method and the declared length and counts the body bytes it receives. A body that goes past the declared length, or that ends at a different length through END_STREAM on DATA, on the headers or on trailers, is a stream error with PROTOCOL_ERROR. RFC 9113 8.1.1 makes it malformed: "A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the content, unless the message is defined as having no content", and malformed responses MUST be treated as a stream error of type PROTOCOL_ERROR.

Identical duplicate content-length headers are accepted, differing values fail with :disagreeing_content_length_headers, and values that aren't digits fail with {:invalid_content_length_header, value}. HTTP/1 keeps :more_than_one_content_length_header, since there any second content-length header is an error. The digit check is Mint.ParsingTools.only_digits?/1, which Mint.HTTP1.Parse now uses too instead of its own copy.

Responses to HEAD, and 204 and 304 responses, are the cases RFC 9110 6.4.1 says never carry content. They're tracked with a length of zero rather than exempted, so a DATA frame on one is a stream error instead of body data, whatever the content-length header says. 2xx responses to CONNECT are exempt from the comparison because they carry tunnel data.

content_length/1 only matches {"content-length", value}. A response with Content-Length never reaches it: header validation from #504 runs first and fails the stream with {:invalid_header_name, "Content-Length"}, since RFC 9113 8.2.1 prohibits uppercase field names.

[coveralls]

Coverage Report for CI Build 8519

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage increased (+0.1%) to 88.77%

Details

• Coverage increased (+0.1%) from the base build.
• Patch coverage: 2 uncovered changes across 1 file (60 of 62 lines covered, 96.77%).
• 22 coverage regressions across 1 file.

Uncovered Changes

File	Changed	Covered	%
lib/mint/http2.ex	58	56	96.55%
Total (3 files)	62	60	96.77%

Coverage Regressions

22 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
lib/mint/http2.ex	22	93.86%

---

Coverage Stats

Relevant Lines:	1781
Covered Lines:	1581
Line Coverage:	88.77%
Coverage Strength:	551.03 hits per line

---

💛 - Coveralls

[whatyouhide]

Left two small comments but logic looks great.