Add arguments for API query parameters when fetching all Dandisets; support creating embargoed Dandisets

[jwodder]

Closes #1413.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.61%. Comparing base (5970a3b) to head (1ed5a55).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1414      +/-   ##
==========================================
+ Coverage   88.58%   88.61%   +0.02%     
==========================================
  Files          77       77              
  Lines       10499    10527      +28     
==========================================
+ Hits         9301     9328      +27     
- Misses       1198     1199       +1     

Flag	Coverage Δ
unittests	88.61% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yarikoptic]

Let's add a test or two.

ATM we do not really test/deal much with embargoed dandisets seems to me, primarily since we do not even expose embargo option:

dandi/dandiapi.py:    def create_dandiset(self, name: str, metadata: dict[str, Any]) -> RemoteDandiset:

So let's as part of this PR expose that option, create also embargoed dandiset and test listing here for a set of query parameters to see that they map correctly to the API call (as you mentioned -- requests would simply ignore if we do not change them from None)

[jwodder]

@yarikoptic

test listing here for a set of query parameters to see that they map correctly to the API call

What exactly should be tested? Should there just be a test for each bool argument that checks that a matching Dandiset is/isn't returned when the argument is true/false?

Note that there can't be a test that checks the entirety of the get_dandisets() return value, as the test Dandisets created for most tests persist in later tests, and it's possible for tests to be skipped or run out of order, so there's no guarantee about what Dandisets will exist in the test Archive when a test runs.

[yarikoptic]

Note that there can't be a test that checks the entirety of the get_dandisets() return value, as the test Dandisets created for most tests persist in later tests, and it's possible for tests to be skipped or run out of order, so there's no guarantee about what Dandisets will exist in the test Archive when a test runs.

I didn't realize that -- I thought that we just have a fixture to populate a number of dandisets and then test on them.

What exactly should be tested? Should there just be a test for each bool argument that checks that a matching Dandiset is/isn't returned when the argument is true/false?

I think testing for that would suffice. Fixture could ensure to populate at least one dandiset to satisfy each criteria, then (with the light of above) - we could test that there is at least one dandiset satisfying the desired criteria.

[yarikoptic]

Thank you!

[github-actions]

🚀 PR was released in 0.61.0 🚀