[FEATURE] Support continuation tokens

[rolaca11]

Is your feature request related to a problem? Please describe.
When nexus responds with a list of items, the response contains a maximum of 10 items and a continuation token, if there are more items. With the current plugin capabilities, I can only get 10 items from my nexus repository.

Describe the solution you'd like
A general solution, where if a continuation token is found, the request is repeated with that continuation token.

Describe alternatives you've considered
I don't think there is a workaround, this feature is put in place as a security measure. You might want a switch that can turn the behavior off. I can see that it might cause problems.

Additional context
I found a site explaining the technique. https://phauer.com/2017/web-api-pagination-continuation-token/ From this, it seems to me that this feature is at least semi-standard in rest apis, even if it seems not to be too popular. Is there a place for a feature like this in the plugin? Is it too specific? Unfortunately, it seems like there isn't a consensus on how the API expects the continuation token. It might be some header or a query parameter.

[h1dden-da3m0n]

I am more surprised that the Nexus API returns any response /s (Have to deal with Nexus 2 + 3 at work and ave grown to hate their usually lacking API for the things I would love to do)

Anyway, my sarcasm and personal grievance with Nexus aside, I am aware of this limitation and had it for the longest time on my ToDo list.
Unfortunately, to my knowlage and basic research that I did when I added this feature to my ToDo list was that there is no unified way that REST APIs handle this.
Take GitHub/GitLab for example their pagination, while similar, has its difference.
IIRC GitLab has the Link header AND extra x-page, x-next-page headers, while GitHub only has the Link header to page.

This plays well into your discovery that there isn no unified agreed way how to handle this. (sidnote: this is not really a security issue rather than a performance one for the API server/client if the responses are too large)

IMHO I am in favour of handling APIs with the Link header (GitHub Docs, GitLab Docs), since I have seen that one used more. Unfortunately there is no 'solution to rule them all' (REST APIs), so this will always be a bit of feature that either works or breaks.

Finally, there is no easy way to handle this with okhttp, unlike Unirest (apparently), however I am confined that changing the request API will have no beneficial effect here either, since that wont solve the problem of API-Developers not handling pagination in a standardized way (cause there doesnt seem to be a standard)

[h1dden-da3m0n]

Regarding your question if this where a desired feature of this plugin, yes it is!
I am up for discussion to find a way to cover as many APIs as possible with the selected solution in the end, but I am afraid that there will always be the one outlier API that will handle pagination different to all others.