✨ Adds support for paginated storage queries, and implements pagination for the wallets_list endpoint

[ff137]

✨ Adds support for paginated queries, and in particular implements pagination to the multitenant.admin endpoint: wallets_list, with new query params: limit and offset.

New default behavior:

• wallets_list will now return a default limit of 100 wallets, with a maximum allowable limit of 10'000.
• 💥 This represents a breaking change because it will no longer fetch all wallets (which is a good breaking change, because it can take minutes to fetch all when there are 100s of 1000s of wallets)

Old behavior is preserved for any BaseRecord.query that doesn't specify a limit or offset, it will still fetch all records.

Additional change that may be worth including: add sort_by query param to wallets_list endpoint, so that the client can customise the sorting used by Askar's scan method. Pending support in Askar.

Notes:

• I added a change to the integration tests workflow, so that it won't run if a PR is marked as a draft. This was to prevent unnecessary integration tests while work was in progress, and I figure it's worth including this on main.
• I removed an option (retrieveTags: False) being passed to BaseRecords' find_all_records method. The retrieveTags option is not used anywhere and has no effect.

[dbluhm]

These changes look pretty logical so far. Something that popped into my head as I was reviewing was the BaseStorageSearch classes, like this one for Askar: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/storage/askar.py#L203

I wondered if it would make sense to use those classes still; however, the storage search would be good for ACA-Py to use internally for iterating through a large collection efficiently but not for providing pagination to an external client.

All that to say that I can't think of a better way to handle this when it's required.

[ff137]

Note: I was able to validate that limit/offset works as expected, and there's no duplicate records across pages. But since there's currently no ORDER BY clause in the askar scan SQL query, there may be inconsistent ordering of results over time.

I've started work separately in aries-askar to allow for custom ordering, so client can have more control over which records are on page 1. That functionality can be introduced in a future PR

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.8% Coverage on New Code
1.9% Duplication on New Code

See analysis details on SonarCloud

[dbluhm]

LGTM