Serialise concurrent WebDAV MOVE and COPY against the same source

[!TIP]

Help move this idea forward

• Use the 👍 reaction to show support for this feature.
• Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
• Subscribe to receive notifications about status changes and new comments.

Is your feature request related to a problem? Please describe.

Two clients issuing a WebDAV MOVE or COPY against the same source key concurrently both proceed. Neither is rejected. Each request drives its own storage-level rename in parallel. Server resources are consumed by both.

Transactional locking does not serialise these operations. The internal lock is held during the filesystem-tree metadata step, not for the duration of the storage-layer rename.

Describe the solution you'd like

A MOVE or COPY request against a source that is already the target of an in-flight MOVE or COPY MUST return HTTP 423 Locked (RFC 4918). The lock MUST persist for the whole duration of the storage operation, not only the metadata mutation.

The mechanism MAY reuse \OC\Lock\MemcacheLockingProvider by holding an EXCLUSIVE lock at the DAV handler entry and releasing it after the storage operation returns.

Describe alternatives you've considered

• Client-side coordination. Not enforceable across heterogeneous WebDAV clients.
• Ingress or reverse-proxy rate limits. Per-IP or per-connection, not per-source-key.
• files_lock app. Targets edit conflicts, not MOVE serialisation (files_lock#228).
• WebDAV LOCK/UNLOCK per RFC 4918 §7. Not surfaced by default (#1308).

Additional context

• Related: #48823 (concurrent MOVE leaves orphan multipart uploads).
• Related: files_lock#228 (existing locks do not block same-user MOVE/rename/delete).
• Declined: #33688 (per-user rate limit for WebDAV).

Start by locating the WebDAV handler entry points for MOVE and COPY and reviewing how \OC\Lock\MemcacheLockingProvider is used. Ensure a source already involved in either operation returns HTTP 423 Locked and that the lock remains until the storage operation returns; verify both MOVE and COPY concurrency paths.