LUCENE-10140: Non-heuristic intervals sub-matches caching

[khitrin]

Description

Minimizing intervals (maybe just ORDERED and AT_LEAST, but not sure) can move sub iterators to non-sub-match position inside match window, but CachingMatchesIterator logic relies on heuristic that any position inside matching interval is a sub-match.

For example: ORDERED("a", "b", "a") over "a b a" highlights (report sub-matches) only "a b a", and ORDERED("a", "b", "a", "b", "a") highlights only "a b a b a".

https://issues.apache.org/jira/browse/LUCENE-10140

Solution

Looks like there is no way to determine the right moment to cache from caching iterator perspective, so I propose to add an interface allowing minimizing IntervalIterators notify sub-sources positioned at sub-match positions.

There is a distinct pointcut for such notification: a slop calculation inside nextInterval.

Also, I think, MinimumShouldMatchIntervalsSource deserves some refactoring after this and I'm not sure that BLOCK is actually a minimizing interval source.

This patch resolving LUCENE-10075 (#270) because it removes extra endPosition() call after reaching last interval.

Tests

Added test for LUCENE-10075 and a new test for "a b a b a" highlighting.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Lucene maintainers access to contribute to my PR branch. (optional but recommended)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.

[khitrin]

@romseygeek , could you please take a look?

[khitrin]

Superseded by #370