db52c00bc3
This was a mess, and hasn't been working for a long time. The test for _more_changes added in this change does not pass prior to this change. The only way we ever communicated that extra results were present out of QueryProcessor was by including one more result. But different pieces of the code were rarely clear on whether they should be expecting an extra result or not. Moreover, there were three different limits that were considered, and they were all given unhelpful names like "limit" and "maxLimit." Improving this situation substantially requires doing something like what the end result is from the REST API: including for each list of results a boolean indicating whether there are more results available. Do this with a QueryResult class encapsulating these fields. This class also includes the original query string and rewritten predicate intermediates, which can help with debugging. After this change, the semantics of the limits should be more clear. The limit computation uses more helpful variable names, and enforces that we always request a limit of n+1 from the secondary index. However, this extra result never escapes to callers in a QueryResult from QueryProcessor. This also required changes to the query rewriter to replace all limit predicates within the query with a fixed value that is always different from any limit predicate in the original query. This may actually make IndexRewriteTest a little easier to understand, as prior to this change a different limit would appear in the IndexChangedQuery portions than at the top level. Change-Id: I4fcf7db0136fd77dbe91b20258ae80a9797a1af9