Paginated API with cursor to Multi

[IsSkyfalls]

Let's say I have an API with the following schema:

{
  ...
  "next": "cursor-to-next-page"
}

and to retrieve the next page, you do GET /api/foo/cursor-to-next-page.

With the current Multi.createBy().repeating() function, by default, each Uni/CompletionStage is initialized without any context of the last result, unless you store that information somewhere:

        Multi.createBy()
                .repeating().uni(()->new AtomicReference<>(""), // if the initial request doesn't have a cursor, we might have a problem in some cases, so a check is needed
                        (holder)->{
                            return doRequest(holder.get())
                                .invoke(holder.set(...));
                        }).until((e)->e.hasCursorNext());

If we need to limit the number of pages, this becomes more complex as we can't use UniRepeat.atMost(5) with `.whilst(Predicate).
My workround is to use a Tuple2 to hold both the AtomicReference and AtomicInteger as a counter.

Another solution would be to use an variable in the function that the Multi is created, but I'm not sure about the performance issue that will cause(context switching maybe), and it still looks bad.

It would be good if the api allows MultiRepetition.uni() to have the result produced by the last Uni.

[cescoffier]

@jponge do you think can we use the internal context support for this?

[jponge]

I'd certainly go into that direction since Mutiny contexts are meant to store such subscription-dependent state.