[SDK 2665] Update endpoint methods to support 'from' and 'take' checkpoint pagination parameters, where appropriate

[evansims]

Changes

This PR updates the following methods to support checkpoint pagination API2 parameters:

• Roles::list_users()
• Organizations::all_organizations()
• Organizations::all_organization_members()

References

• Please see the internal Jira tickets SDK-2666 and related epic SDK-2653 for details on this initiative.

Testing

• This change adds unit test coverage
• This change adds integration test coverage
• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All existing and new tests complete without errors

[lbalmaceda]

I'm seeing now that page/per_page could mean the same as from/take. Have you tried what happens if a call that was using the former now uses the latter? Because if that's the case, all these methods could be simplified in either of these two ways:

• duplicated method signatures, each using its variant.
• keep the old signature, but when building the request, mapping the old variant to the new one.

Might be worth checking with the team if the old properties are deprecated now that the endpoint supports "checkpoint" pagination.

[evansims]

Hey @lbalmaceda 👋 Thanks, I've merged those suggestions.

I'm seeing now that page/per_page could mean the same as from/take.

It's true per_page and take mean effectively the same thing, and each is separately required to activate their respective pagination styles. page and from are unique: page is just an incrementing int for the next page of results, whereas from is (usually) an API-provided UUID to retrieve the next list of results (although /logs treats this slightly differently.) You make the initial request without a from, retrieve the value of next returned from the API response, and make your subsequent request with that value as the from.

This isn't something that could be mapped in the way suggested, unfortunately.

As far as splitting up the endpoint methods for checkpoint pagination variants, we can certainly do that. Personally, this feels like something that should just be handled with method arguments to me — but I'm happy to implement this however you think best suits the SDK.

Have you tried what happens if a call that was using the former now uses the latter?

Checkpoint pagination always takes precedence by the API in handling requests; it falls back to basic pagination when take is missing.

Might be worth checking with the team if the old properties are deprecated now that the endpoint supports "checkpoint" pagination.

No indication from anyone I've spoken with that basic pagination is going anywhere. Checkpoint pagination just addresses the problem of API dataset changes being applied between client API requests, causing a shift in results, which can lead to gaps in data on the client's end.