Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

#1620)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

….0 (#1622)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

* New API, BufferedSource.indexOf(ByteString, fromIndex, toIndex)

This is surprisingly interesting. To minimize unnecessary reads for
toIndex it is necessary to check whether a prefix of the query matches
a suffix of the currently-loaded data.

This read-avoidance is useful in practice. When doing HTTP multipart
decoding the caller may scan for a boundary separator with a bounded
range, and we don't want to block reading when doing so won't impact
the result of the call.

* apiDump

* Check both maximum and minimum prefix sizes

---------

Co-authored-by: Jesse Wilson <jwilson@squareup.com>

The old rangeEquals function was embarassingly inefficient,
using a full scan of the segments linked-list for each element.
That optimization is already done in indexOf(), which has
almost all of what we need for rangeEquals().

This adds an offset and count slice to the input ByteString
in indexOf(), and then leverages that to simplify rangeEquals().

Co-authored-by: Jesse Wilson <jwilson@squareup.com>