Upload File to Directory that was moved by other client (TUS)

## Describe the bug

For this experiment, wo clients sync the same personal space with two desktop clients, one Linux client (A) and one Windows (B).

Both are in sync.

Client B puts a new file into the directory `Moon`. The client B detects that and starts to investigate (which takes long for some unknown reason) and upload.

Before that finishes, client A renames directory `Moon` to `Sun` on his side, which gets synced quickly, so that `Moon` is renamed to `Sun` on the server. Client B's attempt to upload something into `Moon` is a problem now as that dir does not longer exist.

## Steps to reproduce
Do what was described above.

## Expected behavior
On the server, this experiment should result in: The two directories `Moon` and `Sun`. `Moon` should only consist the new file uploaded from client B, while the original files were moved to `Sun`. Is that expectation correct? How is oC10 handling that?

## Actual behavior
The move from `Moon` to `Sun` was executed on the server, so that `Moon` is not longer existing.
However, the previous dir that is still on client B (`Moon`) is not there.

The worst: client B is stuck from now on, not syncing the renamed dir, nor uploading the newly added file into the old dir. Sync is lost.

Interesting: On the `POST` to the non existing directory, ocis answers with the HTTP status code `412 Precondition failed`. One suspicion would be that this is wrong and different to what oC10 does.

The whole request:
```
2022-10-11 14:17:51 POST https://ocis.owncloud.cloudspeicher-bayern.de/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$fb30275a-6e7a-4460-bb70-a336f1c0e9fc
← 412 Precondition Failed [no content] 43.2s
Request Response Detail
Host: ocis.owncloud.cloudspeicher-bayern.de
X-OC-Mtime: 1665490108
Content-Type: application/offset+octet-stream
Upload-Offset: 0
Tus-Resumable: 1.0.0
Upload-Metadata: filename L0tyYW0gaW4gS2xhYXMnIFBlcnNvbmFsU3BhY2Uvb2NpczEuMTIgLSBLb3BpZS4wLXJjMS1saW51eC1hbWQ2NA==,checksum U0hBMSBiYjllMTRmZTgzZjI2ZjE1ZmUyNTg2NDNlZTgxMWZjMzBmYTJiMzNl
Upload-Length: 73505172
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJMejl5VEYyVy1UNGVjZGJGemRRejhLbExjaGtWN0Z1REpVaXdIRmtVT1RJIn0.eyJleHAiOjE2NjU2NDY4MDYsImlhdCI6MTY2NTQ3NDAwNiwiYXV0aF90aW1lIjoxNjY1NDE5NDU1LC
JqdGkiOiI0MTZmMmM3OS1jYzkwLTQ3YTAtODYzNy1jYTViMTkyN2E5ZTgiLCJpc3MiOiJodHRwczovL2tleWNsb2FrLm93bmNsb3VkLmNsb3Vkc3BlaWNoZXItYmF5ZXJuLmRlL2F1dGgvcmVhbG1zL29jaXMiLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiZjo4MDd
lNzI3My0yNmEzLTQ1MDItYjdmMi1mOGEyYTA4NWI5NzY6a2ZyZWl0YWciLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJ4ZFhPdDEzSkt4eW0xQjFRY0VuY2YyWERrTEFleE1CRndpVDlqNkVmaGhIRkpoczJLTTlqYmpUbWY4SkJYRTY5Iiwic2Vzc2lvbl9zdGF0ZSI6
IjEyYmZkZDVlLTRjMGItNGRkZS04MmNkLTY4ZmNlYWU3ZTExNyIsImFjciI6IjAiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsiZGVmYXVsdC1yb2xlcy1vY2lzIiwib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZ
XNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgb3duY2xvdWQgb2ZmbGluZV9hY2Nlc3MgZW1haWwiLCJzaWQiOiIxMm
JmZGQ1ZS00YzBiLTRkZGUtODJjZC02OGZjZWFlN2UxMTciLCJvY2lzLnVzZXIudXVpZCI6ImZiMzAyNzVhLTZlN2EtNDQ2MC1iYjcwLWEzMzZmMWMwZTlmYyIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwibmFtZSI6IktsYWFzIEZyZWl0YWciLCJwcmVmZXJyZWR
fdXNlcm5hbWUiOiJrZnJlaXRhZyIsImdpdmVuX25hbWUiOiJLbGFhcyIsImZhbWlseV9uYW1lIjoiRnJlaXRhZyIsImVtYWlsIjoia2ZyZWl0YWdAb3duY2xvdWQuY29tIn0.kprAJJfGNNBL7ZrSDxr6bbitFZPn7uTr0Y9x-2fwZOZ1AT96ndQqJXDebj-eLN45
kvoN2Hnrl_cOYUF5Jh30nEM1K26upL7exzWNhw3F0SR_kbRvi34oMR6hEM_QHtaEjWB6mgclu8kV6PaHxrIVQjopTnIzvrIqF2Oei1SEkKWf_--zDiFfCFjrTcoOVmGZQbseKSSboiy4atmwFYzkf-1yDkGzvy6K9G7CWt6LFJF_Ft2oL4RdWV5RVEa7VPdia0DCk
8Cn04gD23NSRjTgwO8RVEl9wimBFmwiI_f-hxp51UEy__eo7149h6JfDB6swNWqZGuXz4-uyWFbBblj8A
User-Agent: Mozilla/5.0 (Windows) mirall/3.0.0.0-git (ownCloud, windows-10.0.19044 ClientArchitecture: x86_64 OsArchitecture: x86_64)
Accept: */*
X-Request-ID: 400dbe3a-0f43-4cd5-be75-6c7f30060abc
Original-Request-ID: 400dbe3a-0f43-4cd5-be75-6c7f30060abc
Content-Length: 73505172
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: de-DE,en,*
```

What the client does on `412` is rescheduling a PROPFIND on the same resource, which does not work in this case, because it does not longer exist - and ocis returns a `404` in that case.

## Setup
oCIS experimental branch as server. TUS upload as a result.

I would be helpful to replay the exact scenario with oC10 to see what happens there.