Provide collection to SyncManager

[sunkup]

Purpose

Provides database Collection to SyncManager. This is a prerequisite for #588 , #876 and #878

Short description

Provide collection to

• CalendarSyncManager
• ContactsSyncManager
• JtxSyncManager
• TasksSyncManager

by rewriting sync method in respective syncer classes
and finally provide collection to SyncManager.

Also:

• adapt TestSyncManager

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.

[ArnyminerZ]

Looks good, I like the new approach without that many sub-functions.

[rfc2822]

1. Do you think it would be possible to generalize the process of creating/updating/deleting collections, maybe with an interface or by having the code in `Syncer' and just provide implementation details in the sub-classes? Would be nice if the same code wouldn't be there three times.
2. Can you please re-base/merge the latest changes? I changed the Syncers to use DI.

[sunkup]

1. Do you think it would be possible to generalize the process of creating/updating/deleting collections, maybe with an interface or by having the code in `Syncer' and just provide implementation details in the sub-classes? Would be nice if the same code wouldn't be there three times.

Maybe, I will see what I can do :)

[sunkup]

It's hard.

I have divided the process into 5 stages:

0. Preparations
1. find resource lists (calendars/addressbooks/task lists) to be synced
2. update/delete local resource lists
3. create new local resources
4. sync local resources contents

I tried dividing the process into smaller methods in their respective resource type syncers, which are then called one after another in the base syncer. This only makes the process more complicated and yields more duplicated code. Using an interface with decoratored classes only complicates everything even more.

The problem are the subtle differences between the resource types. I feel that the easiest way to combine all resource types in one process is to throw them all in one method (sync in base syncer) with a lot of if/else statements deciding the subtleties. It would complicate the sync process a little bit more, but we would get rid of the duplicated code and could drop the specific syncer implementations.

That is, we would have one (non-abstract) Syncer, which we'd supply with the authority to be synced. At the moment we also pass the authority to the sync method. So there might actually not be a good gain in having multiple different syncers.

I suggest we try merging the different sync step implementations of the syncers in the syncer, passing the authority along as construction argument and let this one concrete syncer instance handle the whole process for all resource types.

In a new PR though.

@rfc2822 What do you think? Maybe should have a call about it :)

[rfc2822]

👍🏻 As discussed, to be followed up by #896