Add Workspace Metadata

[Mythicaeda]

• Tickets addressed: Closes Metadata for SeqDev Workspace files - Protocol and API #1802 and closes Metadata for Seqdev Workspaces - Managed fields and Read-only flag #1804
• Review: By commit
• Merge strategy: Merge (no squash)

Description

• Adds new endpoints for handling metadata files and update existing file endpoints to reject directly updating metadata files
• Updates the reserved Metadata extension from .aerie to .meta.seqdev
• Updates listContents endpoint to hide METADATA-type files by default, and to provide the contents of the metadata files if the withMetadata flag is provided
• Updates file move/copy/delete so that metadata files are consistently handled before their corresponding file. Before, it varied based on endpoint
• Restricts move/copy/save/delete file endpoints to reject with a 423 Locked status if the file is marked as "readOnly"

Verification

I'd like to add some tests that focus on the contents of the metadata files, and how they're reconstructed after deletion, as well as basic bindings tests for the endpoints.

Documentation

No docs are invalidated, but we should add documenting these new endpoints to writing docs for the other workspace server endpoints

Future work

[Mythicaeda]

For (1), blocking folder delete if there's a readonly file within the folder would implicitly mean that you cannot delete a workspace if it has a readonly file within it, which feels unintentional. Additionally, even for the normal folder case, the spec feels too vague. There's four approaches I can take to this:

1. delete up until encountering a readOnly, then stop when one is reached
2. search the folder (and subfolder) contents for a readOnly before deleting and stop if any are found
3. delete everything that isn't readOnly -- this one actually aligns with the behavior of rm and would be my preference
4. One of 1-3, as well as adding a force flag to delete that will skip the readOnly check

For (2), it looks like I forgot to push the change to copy after the demos -- please repull and retest

[dandelany]

Thanks @Mythicaeda - options 2 and 3 above both seem pretty reasonable. I think option 2 (check ahead of time, don't delete anything if readonly is found) is preferable for a couple reasons - despite being different from how the OS does it, it aligns with our principle of having these ops be as atomic as possible & either completely succeed or fail. It also lines up with the Clipper feedback we've gotten re: wanting as many guardrails as possible to stop them from accidentally deleting a folder they didn't mean to delete.

If possible the error message returned in this case should also call out the paths of any read-only files it finds, to help the user track them down if they do intend to delete.