Race condition when acquiring lock for webdav based accounts

### Which version of floccus are you using?

4.12.0

### Sync method

{"label"=>"WebDAV"}

### Which browser are you using?

Firefox 98.0.1

### Which version of Nextcloud Bookmarks are you using? (if relevant)

_No response_

### Which version of Nextcloud? (if relevant)

_No response_

### What kind of WebDAV server are you using? (if relevant)

Doesn't matter.

### Describe the Bug

A typical sync cycle looks like this in the logfile of a webdav server:
```
2022-03-22T12:36:01.904401Z ip1 bob 404 GET /bookmarks/bookmarks.xbel.lock
2022-03-22T12:36:02.057273Z ip1 bob 201 PUT /bookmarks/bookmarks.xbel.lock
2022-03-22T12:36:02.250949Z ip1 bob 200 GET /bookmarks/bookmarks.xbel
2022-03-22T12:36:06.100949Z ip1 bob 200 PUT /bookmarks/bookmarks.xbel
2022-03-22T12:36:06.791755Z ip1 bob 204 DELETE /bookmarks/bookmarks.xbel.lock
```
The first `GET` request for the `.lock` file seems too check if that account is currently locked and the following `PUT` seems to actually lock the account, it it was unlocked (404 response).
There is a race condition (here approx. 150ms). When a second client does the same `GET` for checking for the `.lock` file before the `PUT` for the `.lock` file of the first client both think nothing is locked and do the `.lock` file `PUT`. If both have changes, the slower one will win, as this `PUT` for the data request happens later and will overwrite the changes of the faster client.

To solve this the `GET` and `PUT` for the `.lock` file must be done atomically. WebDAV has the [`LOCK` method](https://datatracker.ietf.org/doc/html/rfc4918#section-9.10),) which, if used, should solve the issue, right?

### Expected Behavior

No race condition.

### To Reproduce

Didn't try to reproduce, just thought about it so far.

### Debug log provided

- [ ] I have provided a debug log file