Store `embargo_end_date` on dandisets directly

[jjnesbitt]

Related to #1286 and #2729

That issue and PR made me realize that if we're going to start relying on the embargo end date of a dandiset, we should probably store it in a field that the user can't modify. At the moment, since the embargo end date is only stored within the metadata, it could be overwritten by someone simply using the API.

I think we should instead create a new embargo_end_date field on the Dandiset directly, which would not be modifiable by the user directly. Instead, the value would be set initially on embargoed dandiset creation, and updated upon dandiset unembargo.

This way, the embargoedUntil value within the access metadata field can be computed from the source of truth (the field on the dandiset). It would be trivial to migrate the existing values from embargoedUntil to this new field.

Thoughts @satra @yarikoptic @waxlamp? If nobody objects to this, I could make a PR that supersedes #2729

[waxlamp]

This is yet another piece of evidence that we ought to re-evaluate the meaning of "embargo". But I broadly agree that the embargo end date should be a property of the Dandiset, rather than any Version.

[yarikoptic]

we have it already marked readOnly in dandischema for jsonschema

    embargoedUntil: Optional[date] = Field(
        None,
        title="Embargo end date",
        description="Date on which embargo ends.",
        json_schema_extra={
            "readOnly": True,
            "nskey": DANDI_NSKEY,
            "rangeIncludes": "schema:Date",
        },
    )

and thus in https://github.com/dandi/schema/blob/master/releases/0.6.10/dandiset.json#L39 and I guess it is not modifiable in meditor. But I guess it is modifiable via API?

[waxlamp]

But I guess it is modifiable via API?

Correct! IIUC, the readOnly field is a part of jsonschema, meant to provide hints to consumers of the schema that they may want to prohibit edits to that field (e.g. by making the form disabled, etc.).