Include "dandiset" field in /uploads/initialize/ requests

[jwodder]

Closes #856.

[codecov]

Codecov Report

Merging #863 (9f3f19e) into master (0cc7e59) will increase coverage by 21.27%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master     #863       +/-   ##
===========================================
+ Coverage   65.07%   86.34%   +21.27%     
===========================================
  Files          58       58               
  Lines        6041     6041               
===========================================
+ Hits         3931     5216     +1285     
+ Misses       2110      825     -1285     

Flag	Coverage Δ
unittests	86.34% <ø> (+21.27%)	⬆️

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

Impacted Files	Coverage Δ
dandi/dandiapi.py	89.57% <ø> (+38.11%)	⬆️
dandi/tests/test_keyring.py	100.00% <0.00%> (+3.03%)	⬆️
dandi/metadata.py	81.10% <0.00%> (+3.77%)	⬆️
dandi/dandiset.py	82.89% <0.00%> (+6.57%)	⬆️
dandi/utils.py	79.67% <0.00%> (+8.52%)	⬆️
dandi/download.py	82.44% <0.00%> (+11.96%)	⬆️
dandi/dandiarchive.py	85.99% <0.00%> (+14.00%)	⬆️
dandi/tests/fixtures.py	96.66% <0.00%> (+28.66%)	⬆️
dandi/tests/test_download.py	100.00% <0.00%> (+45.20%)	⬆️
... and 7 more

---

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 6b0259f...9f3f19e. Read the comment docs.

[yarikoptic]

thank you @jwodder ! additional fresh reference to support providing dandiset even for non-embargoed datasets: dandi/dandi-archive#647 (comment) . But I think then we should

• schedule this PR for release (added)
• and declare all prior releases bad in .et
  or should we wait to do the latter some time later for some reason?

[jwodder]

@yarikoptic I know of no reason to wait to update .et. Should that be done in this PR? Also, would we want to update the cli-minimal-version reported by the redirector?

(Side note: etelemetry is currently broken and useless on Python 3.9+; although a fix has been merged, it has yet to be released. @satra Are you a maintainer of etelemetry? Can you make a release or kick someone who can?)

[yarikoptic]

I am curious also how et will use et to announce user that et needs to be upgraded on 3.9? Sounds like chicken and egg issue.
May be we could just rely on 'the cli-minimal-version reported by the redirector' as for deciding if client is good enough? Sooner or later we should stop relying on et anyways to ensure consistency - it should be based on information obtained from the specific API server interacting with directly anyways.

[satra]

@jwodder - new release of etelemetry is on pypi.

[yarikoptic]

Let's merge, and IIRC how et works, we will announce bad versions after release is out