Reset TwoByteMatcher partial match on mismatching byte

[junhyeong9812]

Overview

DataBufferUtils.TwoByteMatcher does not reset its partial-match counter when a byte fails to match after the first delimiter byte has matched. As a result the matcher reports a delimiter match across non-contiguous bytes, which causes StringDecoder (and any consumer of DataBufferUtils.matcher(byte[]...)) to silently drop a character whenever a lone \r appears inside a line. This PR adds the missing reset so the two-byte matcher only matches a contiguous delimiter.

Problem

AbstractNestedMatcher.match(byte) deliberately leaves the fallback (what to do on a mismatch mid-match) to its subclasses: KnuthMorrisPrattMatcher overrides match(byte) to backtrack via its suffix-prefix table, and SingleByteMatcher is stateless. TwoByteMatcher, however, inherited the base method without providing any fallback, so after the first delimiter byte matched (matches == 1) the counter stayed at 1 across any number of non-matching bytes, and a later occurrence of the second delimiter byte falsely completed the match.

For the default delimiters used by StringDecoder.allMimeTypes() (\r\n and \n), decoding "a\rXY\nb":

	first line
expected	a\rXY
actual	a\rX

CompositeMatcher prefers the longest delimiter that matches at a position, so the false \r\n match (length 2) is chosen over the real \n (length 1), and the byte before \n is consumed as part of the delimiter and lost.

Fix

TwoByteMatcher now overrides match(byte) to reset the counter to 0 when the incoming byte is not the expected next delimiter byte, then delegates to super.match(b) — mirroring the structure of KnuthMorrisPrattMatcher (its while loop collapses to a single reset because a two-byte delimiter can only be in a matches == 1 partial state). A genuine contiguous delimiter is unaffected: when the byte is the expected one the reset is skipped and the match completes.

Added two tests: a unit test asserting DataBufferUtils.matcher("\r\n") returns -1 for non-contiguous input, and a StringDecoder test asserting the character before a lone \n is preserved.

[junhyeong9812]

A note on where this belongs, to help with triage: although the change is in spring-core, the affected consumer is the web stack. DataBufferUtils.matcher(byte[]...) backs StringDecoder and CharBufferDecoder, so every WebFlux text or String body decode goes through this matcher.

With the default \r\n + \n delimiters, a lone \r inside a line makes the two-byte matcher report a match across non-contiguous bytes, and the decoder then strips the byte before the following \n - silently dropping the last character of that line. StringDecoderTests in this PR shows it: "a\rXY\nb" decodes to ["a\rX", "b"] instead of ["a\rXY", "b"].

The behaviour dates back to the matcher refactoring in gh-25915 (2020). Happy to adjust the fix or the tests if a different shape is preferred.

[bclozel]

Thanks @junhyeong9812 !

[junhyeong9812]

Thank you for the review and merge, @bclozel. I appreciate you taking the time on it.