Introduce tasks mapping

[sunkup]

This PR extracts DmfsTask builder (build…) and processor (populate…) logic to dedicated classes, without changing the logic itself.

• Move builder/processor logic to separate classes.
• Move tests (only testBuild... methods, since populate... methods don't have tests) - meaning there was no need to create a file DmfsTaskProcessorTest
• Adapt some tests to account for the changes
• Split test testGetTimeZone into three tests

The interesting part happens in DmfsTask (especially add() and update()). The logic of building/populating has not been touched. I, however, saw it fit to add a comment indicating that one needs to "get nextBackrefIdx BEFORE adding builder to batch") as it broke the logic for me when I simplified the code by changing the order.

The huge number of lines comes from moving the methods and tests.

[rfc2822]

Didn't look through the details, but looks good to me in principle.

Feel free to merge if you have tested everything. As soon as the corresponding DAVx5 PR is merged and works, I'll create an alpha/beta version so that we have additional testing.

[sunkup]

As soon as the corresponding DAVx5 PR is merged and works, I'll create an alpha/beta version so that we have additional testing.

Which would that be? The similar PR (calendar): #32 - which this one is based on - does not have a matching DAVx⁵ PR. Or do you just mean the next relevant PR in DAVx⁵ ?

The next one (calendar) in DAVx⁵ would be bitfireAT/davx5-ose#1573 but that one goes with #41

[rfc2822]

Which would that be? The similar PR: #32 - which this one is based on - does not have a matching DAVx⁵ PR. Or do you just mean the next relevant PR in DAVx⁵ ?

Then please one that only updates synctools. I'd like to have the changes in the alpha/beta