Add new_dandiset fixture

[jwodder]

This PR factors out the repeated code for creating a new test Dandiset and uploading files to it into a fixture. It builds on top of/depends on #853 and thus has to be merged after it.

[codecov]

Codecov Report

Merging #874 (6479b96) into master (1585b4d) will decrease coverage by 0.11%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #874      +/-   ##
==========================================
- Coverage   86.66%   86.55%   -0.12%     
==========================================
  Files          61       61              
  Lines        7194     7141      -53     
==========================================
- Hits         6235     6181      -54     
- Misses        959      960       +1     

Flag	Coverage Δ
unittests	86.55% <100.00%> (-0.12%)	⬇️

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

Impacted Files	Coverage Δ
dandi/tests/fixtures.py	97.23% <100.00%> (-0.05%)	⬇️
dandi/tests/test_dandiapi.py	100.00% <100.00%> (ø)
dandi/tests/test_download.py	100.00% <100.00%> (ø)
dandi/tests/test_files.py	100.00% <100.00%> (ø)
dandi/tests/test_upload.py	100.00% <100.00%> (ø)
dandi/utils.py	80.50% <0.00%> (-0.32%)	⬇️

---

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 1585b4d...6479b96. Read the comment docs.

[yarikoptic]

I wonder if both text_ and zarr_ dandisets should become (scope="session") since they look like the ones to be reused for read-only purposes. And have some dedicated new_zarr_dandiset (and similar new_text_dandiset) with scope to the test for the use cases where needed to mutate?

[jwodder]

I think that would only be a good idea if we could somehow prevent the read-only Dandiset fixtures from being modified (both on disk and on the server); otherwise, it'd be too easy to accidentally use the wrong fixture and cause a test failure that ends up being hard to debug. I don't think the repeated recreating of Dandisets slows the tests down all that much.

[yarikoptic]

yeah, inability to guarantee immutability also worried me. I even was reminded today about pytest-dev/pytest#5044 after I thought that such "presumably a read only use of dandist" could be tested in fixture "turndown" code -- then we could catch cases where a test unexpectedly modifies a dandiset. I was thinking that there could be

• code which creates a new dandiset
• test scoped fixture which creates new dandiset only if doesn't exist, yields to the test, verifies that test did not change it. If it did -- destroys pre-created dandiset (so it would be created a new on next run) and .fails the test with a message that immutability assumption was modified.

But I guess it might be all too much for this PR, so I am ok to proceed with this PR as is unless you see interest in above.

[jwodder]

Let's stick with the PR as it is now.