Add support for Keyset- and Offset-based cursor scrolling

[mp911de]

Usage examples:

Repository query methods

interface UserRepository extends Repository<User, Long> {

  Scroll<User> findFirst10ByLastnameOrderByFirstname(String lastname, OffsetScrollPosition position);
}

Scroll<User> users = repository.findFirst10ByLastnameOrderByFirstname("Doe", OffsetScrollPosition.initial());

do {

  for (User u : users) {
    // consume the user
  }

  // obtain the next Scroll
  users = repository.findFirst10ByLastnameOrderByFirstname("Doe", users.lastScrollPosition());
} while (!users.isEmpty() && !users.isLast());

Template API

MongoTemplate template = …;

Query q = new Query(where("firstName").regex("J.*"))
              .with(Sort.by("firstName", "age"))
              .limit(2)
              .with(KeysetScrollPosition.initial());

Scroll<Person> scroll = template.scroll(q, Person.class);

Scroll<Person> scroll = template.query(Person.class)
                               .matching(Query.query(where("firstName").regex("J.*"))
                                              .with(Sort.by("firstName", "age")))
                               .scroll(OffsetScrollPosition.of(10));

Tasks:

• Implementation
• Revisit Sort precedence and limit/skip relationship to CursorRequest for methods accepting Query and CursorRequest types
• Documentation

Limitations:

• Using projections with Keyset-scrolling requires all keyset properties to be present in the target projection type

Closes #4308
Depends on spring-projects/spring-data-commons#2787

[christophstrobl]

Queries that either sort by or project on synthetic fields, such as { $meta: "textScore" }, cannot utilize keyset pagination.
Sorting by eg. { score: { $meta: "textScore" } } would need us to include the last seen score in the request for the next Window leading to something like {"$text": {"$search": "spring"}, "score" : {"$gt" : 0.5 }} which returns an empty result cause the stored documents do not contain a score field.
To support this feature we'd have to internally convert the Query into an Aggregation that uses a [$match, $project, $match] pipeline that runs the the raw query, additionally projects on the score and then matches against the score in the third stage. It would be good the get some input from MongoDB if they see value in this approach.

[christophstrobl]

That we have to ask ourselves this is an indicator that maybe the request should not be allowed to redefine sorting.

[christophstrobl]

we're ignoring the targetClass here. Might be worth to call doFind(createDelegate(query), collectionName, keysetPaginationQuery.query(), keysetPaginationQuery.fields(), sourceClass, targetClass, new QueryCursorPreparer(query, keysetPaginationQuery.sort(), limit, 0, sourceClass)); instead.

[mp911de]

targetClass is considered in ReadDocumentCallback. We might want to switch to ProjectingReadCallback though. Same for the imperative template.

[christophstrobl]

field projections using expressions work fine since those cannot be used for sorting.

q.fields().project(valueOf("firstName").length()).as("nameLength").include("firstName", "age");