Lock dandiset when changing owners

[naglepuff]

Fixes #2000

Changes

The users endpoint for the Dandiset View now uses select_for_update. This prevents accidentally saving stale data when calleding dandiset.save().

[mvandenburgh]

In addition to the point about the code comment, as I look at this more closely I'm having second thoughts about locking the dandiset in this manner. TLDR: I think your original solution is actually better.

We discussed this before and decided to just lock the dandiset for the duration of the entire endpoint, as is implemented here, in order to eliminate an extra DB query. But I realize now that we only need the lock when the user is sending a PUT request to modify the dandiset owners. The vast majority of calls to this endpoint will not do that, but will instead be a GET request that simply retrieves the owners list (where no lock is needed). That GET request to /users/ happens on every load of the DLP (i.e. probably 99% of calls to this endpoint are GET requests), so with the current approach we'd be adding the overhead of opening a transaction and holding a row lock to every DLP page load.

So I think I'm now convinced that your original solution of re-querying for the dandiset with SELECT FOR UPDATE is better, @naglepuff. What do you think?

[mvandenburgh]

LGTM

[dandibot]

🚀 PR was released in v0.5.0 🚀