Add an optional lock_id argument to storage methods

[glpatcern]

Follow up of #162: the storage methods that modify a resource now have an optional lock_id argument, such that storage provider implementations can enforce the lock validation.

In addition, also the InitiateDownloadRequest has this extra argument, in order to honor exclusive locks. The assumption then is that stat and metadata read operations are always allowed (when access rights are met), such that e.g. the web UI can show users that "File important_stuff.txt is locked in exclusive mode by user bob".

[butonic]

I think these messages also need a lock_id:

• CreateContainer
• TouchFile
• RestoreFileVersion
• RestoreRecycleItem

they all might end up writing into a locked resource

[glpatcern]

We looked at those too:

• CreateContainer and TouchFile expect to create a resource and must fail if it exists
• Restore actions indeed may need the lock_id argument, going to add it

[glpatcern]

I ended up adding the lock_id argument also to OpenInApp, though this is far-fetching: it would be needed when exclusive locks are implemented.

[glpatcern]

@butonic not sure why I can't ask you to review again, anyway could you have another look? I'd go ahead and merge this as is, in case we can keep adding further lock_id arguments if we deem it needed.

[ishank011]

In addition, also the InitiateDownloadRequest has this extra argument, in order to honor exclusive locks

Should we also enforce it for List, since it is equivalent in case the exclusive lock is for a directory?

[ishank011]

Can we also rename Unlock to ReleaseLock?

[ishank011]

For RestoreFileVersion and RestoreRecycleItem, we should specify that the lock is for the restore path

[glpatcern]

Can we also rename Unlock to ReleaseLock?

As discussed, Unlock came from the WOPI terminology, so we leave it as is.

Otherwise, I expanded the spec for RestoreRecycleItem.

[glpatcern]

Should we also enforce it for List, since it is equivalent in case the exclusive lock is for a directory?

As a matter of fact locking a directory was not taken into account so far. I think we should put a comment that although SetLock supports any reference, the semantics of locked containers are not specified at this stage.