Generalize Syncer

[rfc2822]

Currently: 4 Syncers with duplicated code

Goal:

• one generalized Syncer algorithm
• reasonable tests for it (see Tests for sync algorithm #950)
• specific implementations for the data types
• (+ ideally tests for them)
• Syncer should always check permissions / acquire ContentProvider on its own
• keep future error handling in mind (Sync: re-factor error handling #887)

Important: The current Syncer doesn't close the acquired (address book) content provider! (Fixed in #910, but remember to close it when moving to syncer implementations)

 D  [util.BroadcastReceiverFlowKt] Unregistering broadcast receiver for Action: "android.os.action.POWER_SAVE_MODE_CHANGED"
 W  ApkAssets: Deleting an ApkAssets object '<empty> and /data/data/at.bitfire.davdroid/code_cache/.overlay/base.apk/' with 3 weak references
 D  StrictMode policy violation: android.os.strictmode.LeakedClosableViolation: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
    	at android.os.StrictMode$AndroidCloseGuardReporter.report(StrictMode.java:2007)
    	at dalvik.system.CloseGuard.warnIfOpen(CloseGuard.java:336)
    	at android.content.ContentProviderClient.finalize(ContentProviderClient.java:651)
    	at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:370)
    	at java.lang.Daemons$FinalizerDaemon.processReference(Daemons.java:350)
    	at java.lang.Daemons$FinalizerDaemon.runInternal(Daemons.java:322)
    	at java.lang.Daemons$Daemon.run(Daemons.java:131)
    	at java.lang.Thread.run(Thread.java:1012)
    Caused by: java.lang.Throwable: Explicit termination method 'ContentProviderClient.close' not called
    	at dalvik.system.CloseGuard.openWithCallSite(CloseGuard.java:288)
    	at dalvik.system.CloseGuard.open(CloseGuard.java:257)
    	at android.content.ContentProviderClient.<init>(ContentProviderClient.java:112)
    	at android.content.ContentResolver.acquireContentProviderClient(ContentResolver.java:2594)
    	at at.bitfire.davdroid.sync.Syncer.onPerformSync(Syncer.kt:85)
    	at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.invokeSuspend$lambda$0(BaseSyncWorker.kt:297)
    	at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.$r8$lambda$iPlAcxGWBi9BGTp3aIafzFPxuss(Unknown Source:0)

Depends on #875

[github-actions]

This PR/issue depends on:

• Provide database Collection to SyncManager #875

[rfc2822]

@sunkup I have noticed that the current Syncer from #881 doesn't actually synchronize after the first sync.

Steps to reproduce:

1. Create DAVx5, set up account, enable a calendar.
2. Sync.
3. Watch logs (if you want, also server logs to be sure): CalendarSyncer creates the calendar and syncs it as expected.
4. Sync again.
5. Watch logs (if you want, also server logs to be sure): CalendarSyncer runs, but doesn't actually synchronize the collection.

This is quite bad because it prevents testing / reproducing other problems with DAVx5 from the main branch.

Do you think this issue should be addressed in a separate issue/PR before this one (and then use this one only for refactoring) or shall we just do it all at once?

[sunkup]

@sunkup I have noticed that the current Syncer from #881 doesn't actually synchronize after the first sync.

Oh, quite bad indeed.

Do you think this issue should be addressed in a separate issue/PR before this one (and then use this one only for refactoring) or shall we just do it all at once?

I have a hunch on why it happens, I think we should address it in a separate issue and PR though. I will create one and work on it straight away :)

[sunkup]

Tracked in #909 Fixed in #910

The PR #910 will also close the acquired provider in the abstract syncer.

The changes should be easy enough to merge into this PR, or simply be re-created accordingly :)