Ensure recurrenceId is parsed from the network reply correctly

See merge request !82

[buteo-sync-plugins-social] Pass recurrenceId to the network reply as a QVariant. Contributes to JB#52657

Various items of data are attached to the QNetworkReply for use when the
reply returns. The recurrenceId was being parsed in as Qt::ISODate
format, but written out as Qt::TextDate format. As a result, the
recurrenceId was always empty, and the parent recurring event was being
amended by the upsync response rather than the exception.

This change attaches the recurrenceId property to the QNetworkReply
object as a QVariant, so that it's restored correctly.

[buteo-sync-plugins-social] Fix parsing of event timestamps. Fixes JB#52645

See merge request !81

The KDateTime-specific formatting should no longer be used. Dates
should be parsed in either ISO format or the yyyyMMddThhmmssZ format.

[buteo-sync-plugins-social] Port to KF5CalendarCore. JB#47814

See merge request !80

Allow sync to continue on delete event error

See merge request !73

[buteo-sync-plugins-social] Keep track of additions for later modifications in the same sync. Contributes to JB#51507

If an event is added during a sync, its details must be kept track of in
case further modifications occur to the event (e.g. exceptions to or
deletions from the recurrence rule) later in the same sync.

The additions were already being carefully ordered to ensure they're
inserted first, but there were some details not added to the maps for
finding the parent event later. This change inserts the event details in
these maps as the sync progresses so that later modifications can be
applied successfully.

[buteo-sync-plugins-social] Set recurrence start time when converting from json. Contributes to JB#51507

The recurrence rules store the event start time separately from the
event itself. If set incorrectly (or not at all) the rules end up being
badly formed, and other actions (e.g. dissociating event exceptions)
could fail.

Events extracted from the database have recurrence start times
automatically set to the event start time, but this wasn't happening
during json deserialisation. This change adds it in.

The issue was triggered when an update for the main event was received
from google (resulting in a json deserialisation), followed in the same
sync by a new recurrence exception for the same event. In this case, the
dissociation for the recurrence was failing due to the lack of start
time in the recurrence rule. If the changes were received in separate
syncs the problem didn't arise, since the main event had been "washed"
through the database.

Whenever an event from a recurring series is given an exception event
(e.g. a single event in the series is edited), a new child event is
created for the exception.

mkcal also adds an EXDATE to the recurrence rule for the parent to
remove the original entry that was edited. In contrast, Google doesn't
add an EXDATE, but just automatically performs the removal.

This causes problems for syncing.

This change adds the extra EXDATEs to the recurrence rules of downsynced
events as needed by mkcal, and removes them from the recurrence rules of
upsynced events.

[buteo-sync-plugins-social] Record sync time as time started, rather than time ended. Contributes to JB#51507

This change records the time at the start of the sync and uses this as
the previous sync time. This ensures that any events modified after the
start of the sync will be uploaded in the next sync.

Deleted events (both local and remote, where the change is already on
the server, are also now purged from the database after a successful
sync to avoid any attempt to upload the deletion to the server on the
next sync (which would cause an error).

These changes don't affect functionality, the aim is only to improve
code clarity.

Various parts of the code (notably in the finalCleanup() method) were
already assuming that the adapter would service only a single account
during its lifetime.

This change removes the additional code needed to support multiple
accountIds, which was going unused.

The deleted and modified times of events are stored using the client
timestamp. If the timestamp returned by the server is used to determine
the upload delta, this can result in the wrong entries being uploaded.
In particular it was resulting in events deleted on the server being
uploaded as new deletions to the server, causing an error.

This change sets the notebook last sync time using the current client
timestamp, to ensure only entries changed after the latest sync are
uploaded to the server.

In the reverse direction the server uses a sync token to determine which
events to sync, so the change doesn't affect which events are
downloaded.

If an error is triggered due to an event being deleted that's already
been deleted from the server, this change allows the sync to continue.

This ensures the account doesn't have to be recreated to fix the issue
on the client.

[buteo-sync-plugins-social] Transform untransformed Google Contact avatars. Contributes to JB#51976

See merge request !79

If a previous sync cycle (using a previous version of the sync plugin)
had caused Google Contacts to be stored to the database with remote
avatar image URLs, then we need to correct that on subsequent sync
cycles by detecting that this has occurred for a contact, and treating
the contact as remotely modified.

[buteo-sync-plugins-google] Further improve Google Contacts avatar sync. Contributes to JB#51976

See merge request !78

If some avatars were not downloaded due to transient error, request
throttle, etc, then we should ensure that we download those during
subsequent sync cycles.

Also, ensure that we only trigger avatar downloads once all other
sync requests are complete, to avoid throttling of sync requests.

[buteo-sync-plugins-social] Allow building only parts of the project

See merge request !67

[buteo-sync-plugins-social] Fix Google contact avatar sync. Contributes to JB#51976

See merge request !77

The avatars must be transformed prior to when they are stored in the
local database, so don't delay that operation until the next event
loop.  In order to avoid the (potential) QNAM crash, delay the call
to AbstractImageDownloader::queue() instead.

[buteo-sync-plugins-social] Don't set Google gd:fullName as customLabel field. Fixes JB#51831

See merge request !76

The customLabel field is used as the default display label in the
QtContacts backend, and since the customLabel for a Google contact is
only updated during a sync operation, the customLabel (and hence the
contact's display label) was not updated when the contact name changed
outside of a sync operation.

It's not necessary to set this as the customLabel field in any case,
because we need to always send the latest version of the formatted name
(according to any local name changes for the contact) in order to avoid
spurious modification notifications from the server.

[buteo-sync-plugins-social] Use low priority on twitter notifications. Contributes to JB#51797

See merge request !75

[buteo-sync-plugins-social] Delay downloading of avatars. JB#22610

See merge request !74

Starting avatar downloads immediately after the last request has
finished causes a crash in QtNetwork.

[buteo-sync-plugins-social] Fix bugs in Google Contact sync. Contributes to JB#51541

See merge request !71

When upsyncing contacts, the server will reply with an updated etag
for each contact in postFinishedHandler(). Save the etags to their
contacts before calling localChangesStoredRemotely(), which will save
the updated contacts to the database. Also save the avatars at this
point instead of in finalize(), as calling QContactManager::saveContacts()
will flag the contacts as modified and cause spurious modification
detections on the next upsync.

Also:
- Ensure the correct detail is looked up for the etag data
- Don't remove contacts from the localAdded/Modified lists in
batchRemoteChanges(), because these lists are then passed onto
localChangesStoredRemotely() for saving
- Save the last sync time in finalize() so that it is not saved if the
sync failed.

Encode and decode the gd:fullName entry in the atom feed. The server
always sends a fullName composed from the first name, last name,
prefix etc. so encoding this in the request will avoid a spurious
modification from the server on the next sync after it reassembles the
fullName on the server side.

We no longer hardcode the name of the default My Contacts collection,
so when searching for it we cannot look for the hardcoded name.
Instead, mark the collection with a special piece of metadata.

Also fix a bug in etag detection.

Finally, ensure we ignore detail access constraints when updating
detail data during sync.

[buteo-sync-plugins-social] Remove ssu dependency. Contributes to JB#38781

See merge request !70

Doesn't seem needed anymore. Commit 13e017fe removed the only need(?)