This came up during development of the audit functionality. It turns out
that add_owner() was only called during Dandiset creation to add the
creating user as the only owner, and remove_owner() is never called.
Instead, in the method that changes the owner set, assign_perm() is used
in all cases to add and remove owners as needed. Since no other point of
use exists for adding/removing users, it makes sense to remove these
methods.

Retrieving the metadata fresh from the model enables two things:
1. To report all "computed" metadata values that are derived from the
   supplied metadata.
2. To enable a changed `name` field on the Dandiset model to be properly
   reported via the metadata.

The `add_asset_to_version()` service function represents essential
complexity in the actual domain. We may be able to simplify it by
refactoring the function into smaller parts, but we will look into that
independently.

Now that the audit records are generated within service functions, it
makes less sense to leak the detail of an AuditRecord instance coming
from the function that must then be saved to the database--the service
itself can just take care of this.

The `blob`/`embargoed_blob` distinction was removed in the embargo
redesign.

The notes in the "avoid catching exceptions" callout here
(https://docs.djangoproject.com/en/5.0/topics/db/transactions/#controlling-transactions-explicitly)
say to do something like this to isolate error handling without stepping
on the operation of the transactions themselves.

Co-authored-by: Jacob Nesbitt <[email protected]>

…ackend