Allow unlocking a folder with rollback of metadata

[allexzander]

Is your feature request related to a problem? Please describe.
If we update the metadataKey in the users array in the top-level E2EE folder's metadata and then fail to re-encrypt the nested folder's metadata, and then unlock the parent folder later (before 24 hours passed), the metadata update will get committed to the top level folder but not nested folders. This will result in data loss as we won't be able to decrypt nested folders' metadata.

Describe the solution you'd like
We need a new functionality in the E2EE API for DELETE lock/ requests. Currently, deleting the lock (or unlocking the E2EE folder) will commit the metadata we've sent via PUT meta-data/ requests. What we need, is to ability to pass a parameter or a header to roll back the metadata state for all folders that were locked with a POST /lock request. This is needed because, when implementing E2EE sharing, we've introduced an array of "users" in the top-level folder, and when adding a new user we first update the metadata of the top-level folder and generate a new metadatakey, and then we re-encrypt metadata of all the nested folders. If there is an error (power or network went down, a server was unreachable), and we fail to update the metadata of subfolders using the new metadatakey that we already updated in the top folder, we won't be able to decrypt those nested folders anymore.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Currently, the rollback happens if we did not unlock the folder and 24 hours passed, according to @tobiasKaminsky. We need to have a way of manual rollback by calling DELETE /lock with certain parameter/header.

[allexzander]

@tobiasKaminsky As discussed, created this issue

[artonge]

Closing, as the feature is developed and no I received no negative feedback from client team.