Attempt to deal with deadlocks by retrying the transaction

This is the recommended approach by mysql.

We're seeing deadlocks by queries such as (find them using SHOW ENGINE
INNODB STATUS):

• DELETE FROM syncroton_content WHERE device_id = '322047a7a0dc73f9c6df5b0dd029e0328257db8a' AND folder_id = '1c483caa62a35d1e0064ed3556196b326d8782f4' AND is_deleted = 1
• INSERT INTO syncroton_content (device_id, folder_id, contentid, creation_time, creation_synckey, id) VALUES('80d4c9dc587966f94004b1f3d18d33b78c022176', 'e73325c2855ae26b46baef5464bf2cd1c89c9f37', 'CRC8139F395e3f342a0-b046-4729-9f9d-ed9c620ecccb', '2023-05-03 15:11:50', '5', '11e2ed496933efe511d666927e7c44c18f5ec821')

It seems difficult to get rid of the deadlock potential (the deadlocks
probably happen on indexes, and don't require to be operations on the
same device or folder). According to upstream, the recommended approach
when encountering a deadlock is to just retry the transaction, so we'll
try just that.

Regarding the above DELETE FROM query; this deadlock could potentially
be avoided by *not* deleting them in an otherwise read-only interaction
in kolab_sync_backend_state::validate (not sure why it's currently done
there though...).