Showcase dynamic entity view collection mapping pagination, filtering and sorting

[beikov]

This is one of the best fitting use case for Blaze-Persistence (Core, GraphQL, Entity-Views) and Blaze-Expression, yet we still have a few missing pieces. Let's build a GraphQL example and add features to our base technologies until we can fulfill this use case perfectly.

My goals are:

• Integration of blaze-expression filters for entity view collection mappings (this part might have to move to blaze-expression)
• Dynamic filtering, sorting and pagination of collection mappings through EntityViewSetting API
• Integration of our "common" pagination related names into the GraphQL integration

The last part is a bit "tricky" as we have to decouple the method signature that is required for schema generation to work properly, from the actual entity view mapping. For SmallRye and SPQR we will have to define a mapping similar to this:

@CollectionAttributeFilter(BlazeExpressionFilter.class)
@CollectionLimit(CustomLimitProvider.class)
Set<SubView> getChildren();
// Fake method to trick GraphQL runtime
default Set<SubView> getChildren(
            @Name("first") Integer first,
            @Name("last") Integer last,
            @Name("offset") Integer offset,
            @Name("before") String before,
            @Name("after") String after) { return getChildren(); }

The fake method might be required, but ideally, I'd like to tell users they just have to stuff an annotation on the regular method instead to get the desired schema.

@CollectionAttributeFilter might be something that will emerge out of https://github.com/Blazebit/blaze-persistence/issues/109 which will be used to filter elements of a collection to a subset. The idea is to extend the EntityViewSetting API a bit to support this case. It should work with all fetch strategies.

@CollectionLimit might be something new, but similar to @Limit. Maybe we can even reuse @Limit directly. The idea here is that the ordering and limit/offset can be passed in through the EntityViewSetting API instead and be optional by default, so this would be more of a representation thing rather than a semantic mapping.