A lot of the code dealing with collections assumes that the editing is
done by the owner (true assumption, for now), and therefore the encryption
key is derived from the master key (not true anymore, as it could be a
stored version of the old key). This commit removes this wrong assumption.
This fixes a bug with deleting entries that were never synced before. To
reproduce:
1. Turn off wifi + data (to ensure nothing is synced).
2. Add an entry (event/task/contact).
3. Delete that entry.
4. Turn wifi + data back on
5. Hit sync
This was an annoying remanent from DAVDroid. Maybe it makes sense for
DAV, but it defo doesn't make sense for us where we can just create
collections (and anyhow always have existing defaults!).
This should never happen, but it has:
kotlin.TypeCastException: null cannot be cast to non-null type com.etesync.syncadapter.resource.LocalContact
at com.etesync.syncadapter.resource.LocalGroup$Companion.applyPendingMemberships(LocalGroup.kt:66)
at com.etesync.syncadapter.syncadapter.ContactsSyncManager.postProcess(ContactsSyncManager.kt:122)
at com.etesync.syncadapter.syncadapter.SyncManager.performSync(SyncManager.kt:169)
at com.etesync.syncadapter.syncadapter.ContactsSyncAdapterService$ContactsSyncAdapter.onPerformSync(ContactsSyncAdapterService.kt:59)
at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:259)
We call it at post process exactly because we want to make sure that all
the members already exist.
I guess a deletion on a misbehaving client (maybe even the web client?)
can cause this. Potentially also with some DAV clients.
Anyhow, it's better to be more defensive here.
Fixes a potential crash when e.g. importing a file with a group that has
members that don't actually exist (e.g. importing a partial vcf).
This change also fixes importing files that have the groups show up
before their members.