Store modseq with the synckey
We store the modseq info belongs to the synckey because we want to be
able to list the changes since the last sync.
By storing the modseq info with the synckey we make sure that the
modseq info remains available as long as the sync key is relevant,
and is then automatically cleaned up with the sync key.
This in particular fixes the cases where a sync request is sent multiple
times, where previously we would overwrite the modseq info after the
first attempt, and subsequently fail to return the changes.
I opted for the generic "extraData" approach, instead of changing the
modseq table with a foreign key constraint on the synckey (which would
also work I think), because I suspect we'll need the same thing for dav.
Performance wise I don't think it matters either way.
Notes:
- We should probably further remove the idea that we are syncing "time windows". We're really syncing based on sync-key entries with some metadata (modseq, dav's equivalent, worst case fallback to timestamps).
- The "getExtraData()" approach to store modseq is a bit convoluted, this could perhaps be solved better with some refactoring.
Differential Revision: https://git.kolab.org/D4662