[sync] Fix endless upload loop when a locally modified resource was deleted on the server

[sunkup]

Purpose

Fixes #2739: a resource that is modified locally and deleted on the server by another client is uploaded again in every sync, forever. Some servers (like DAViCal) answer 412 instead of 404 to our conditional PUT, because per RFC 9110 13.1.1 an If-Match against a non-existing resource must fail with 412. We treat every 412 as "modified on the server in the meanwhile" and ignore it, so the resource stays dirty — but it can never be downloaded, and deleteNotPresentRemotely() skips dirty rows, so nothing resolves it. Affects contacts and events, too.

Short description

• Added SyncManager.uploadTargetIsGone(), which sends a PROPFIND to find out whether the upload target is still on the server.
• The 412 and 409 branches of uploadDirty() now use it: if the resource is gone, the upload is retried as a fresh upload (forceAsNew) — the same resolution we already apply when a server answers 404.
• If the resource is still there, or if the server doesn't give a clear answer, the previous behavior is kept, so a genuine edit conflict is still resolved in favor of the server version.

Related: RFC 9110, section 13.1.1.

Checklist

• The PR has a proper title, description and label.
• I have self-reviewed the PR.
• I have added documentation to complex functions and functions that can be used by other modules.
• I have added reasonable tests or consciously decided to not add tests.

[rfc2822]

I think we need to fully understand and evaluate our 4xx (especially 404/412) handling before we can modify it.

See #2739 (comment) – but needs proper verification and then we can choose an approach. We should probably have a common understanding first.