Add pagination to Clients and Connections

[lbalmaceda]

What

This PR adds pagination support on MGMT API entities that were missing.

Scope

• Clients
• Connections
• Users (Already available)
• Logs (Already available)

Discussion

• While pagination is going to be enforced on new tenants, existing tenants can still call the endpoint without a page value and in turn, retrieve the full list of items. However for this specific SDK, the entities that already had pagination implemented had a default page value of 0, meaning if a specific page is not asked, the first one is always returned. On the present PR the new entities supporting pagination don't have the same behavior. Instead, they skip sending the page parameter if no value is specified. Should we maintain the same pagination behavior as other entities or avoid a possible breaking change?

How it was tested

I re-used the existing tests and added a few similar. I noticed the tests were actually checking the arguments with which the method was being called. One of the checks was that the arguments matched against a given (expected) dictionary value. This dictionary included keys with None value (A Python type similar to JS's undefined). My concern was that these keys were being set as query parameters anyway, sending invalid values on the server request. I added logging support (for testing purposes, not committed to this PR) and tried locally to see what was the actual outcome. Below is an example showing how the parameters are not added to the call if they are of type None.

# test/management/test_clients.py
        c = Clients(domain='domain', token='jwttoken')
        c.all(page=7, per_page=25)

        args, kwargs = mock_instance.get.call_args

        self.assertEqual('https://domain/api/v2/clients', args[0])
        self.assertEqual(kwargs['params'], {'fields': None,
                                            'include_fields': 'true',
                                            'page': 7,
                                            'per_page': 25})

# The final request URL (from my terminal)
        GET /api/v2/clients?include_fields=true&page=7&per_page=25

[codecov-io]

Codecov Report

Merging #106 into master will increase coverage by 0.09%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #106      +/-   ##
==========================================
+ Coverage   93.05%   93.15%   +0.09%     
==========================================
  Files          32       32              
  Lines         634      643       +9     
==========================================
+ Hits          590      599       +9     
  Misses         44       44

Impacted Files	Coverage Δ
auth0/v3/management/clients.py	100% <100%> (ø)	⬆️
auth0/v3/management/connections.py	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b3353b...a0eb1b2. Read the comment docs.

[cocojoe]

LGTM Although I'm not a Python dev 😄 Tests look good though.

[markprovan]

Initially I thought it would be good to get the request url into a unit test, but on digging into auth0/v3/management/rest.py I realised this would just be testing the requests package.

Looks good! 👍

[lbalmaceda]

@markprovan @cocojoe similar to what I mentioned in the description, in the libraries I own I'd test the actual outcome instead of the params being passed to the function. So tests would check the final URL, query parameters and body instead. I don't care about what the method does internally. That shouldn't matter for the purpose.