Improve efficiency of BoundedBreakIteratorScanner fragmentation algorithm

[thelink2012]

This is PR #75306 (a fix for PR #73785) but in an user-repository such that Allow edits by maintainers is possible. As follows is a description of the original PR. See those other PRs for previous discussions.

As discussed in #73569 the current implementation is too slow in certain scenarios.

The inefficient part of the code can be stated as the following problem:

Given a text (getText()) and a position in this text (offset), find the sentence boundary before and after the offset, in such a way that the after boundary is maximal but respects end boundary - start boundary < fragment size.

In case it's impossible to produce an after boundary that respects the said condition, use the nearest boundary following offset.

The current approach begins by finding the nearest preceding and following boundaries, and expands the following boundary greedily while it respects the problem restriction. This is fine asymptotically, but BreakIterator which is used to find each boundary is sometimes expensive [Lucene noticed too].

The new approach maximizes the after boundary by scanning for the last boundary preceding the position that would cause the condition to be violated (i.e. knowing start boundary and offset, how many characters are left before resulting length is fragment size). If this scan finds the start boundary, it means it's impossible to satisfy the problem restriction, and we get the first boundary following offset instead (or better, since we already scanned [offset, targetEndOffset], start from targetEndOffset + 1).

In theory, both approaches should produce exactly the same outputs given the same (text, offset, fragment_size) tuple. But it doesn't. As far as my investigation went, BreakIterator doesn't seem to be commutative. Previous method calls affects other calls. So I guess whatever change we make to this algorithm, may produce results that differ from each other. It is rare, but happens. Would love to be wrong on this though.

Highlighting related unit and integration tests pass. Though I'm not passing in tests that seem completely unrelated to this. See below.

[romseygeek]

@elasticmachine ok to test

[elasticsearchmachine]

Pinging @elastic/es-search (Team:Search)

[romseygeek]

@elasticmachine generate changelog

[romseygeek]

@elasticmachine update branch

[pugnascotia]

@elasticmachine generate changelog

[romseygeek]

LGTM, thanks @thelink2012

[thelink2012]

Hey @romseygeek. Thanks for the merge. Would it be possible for this patch to be backported to previous versions (at least 8.4)?

[javanna]

heya @thelink2012 we only backport bug-fixes to patch releases, and this does not qualify as one.