Remove address books sync authority and content provider

[sunkup]

Purpose

Before using workers for automatic sync, we needed the "address books" sync authority and content provider so that sync intervals could be set for address books. There is no other purpose for the address book sync authority and so we can remove it now.

Short description

This PR removes both the address books sync authority and content provider and updates usages.

• drops address book provider and sync adapter service
• address books authority string is still used representatively (ie for setting/getting sync interval)
• allows to get the sync interval for addressbooks even when not sync enabled in the Sync Adapter Framework anymore

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.

[rfc2822]

This may technically work, but it would be difficult to understand because the (main) accounts are not syncable for contacts. So it's not understandable why we'd use the contacts authority with them.

I suggest to keep R.string.address_books_authority, make sure that it's only a constant (i.e. it doesn't actually refer to a content provider) and just remove the content provider.

In a separate PR, we should replace the authorities by CONTACTS/CALENDAR/TASKS constants where this makes more sense. I'll create a new issue for that.

[rfc2822]

See #880

[rfc2822]

Looks good, but there are problems:

1. After creating an account with our test server, address books are correctly detected, but the account settings don't have a "contacts sync" interval:

   Screenshot

   

2. Address book synchronization doesn't work:

 D  [settings.AccountSettings] Account [email protected] has version 15, current version: 15
 I  [sync.worker.BaseSyncWorker] Manual sync, skipping network checks
 E  Failed to find provider info for at.bitfire.davdroid.addressbooks
 W  [sync.worker.BaseSyncWorker] Couldn't acquire ContentProviderClient for at.bitfire.davdroid.addressbooks
 I  [sync.worker.BaseSyncWorker] OneTimeSyncWorker finished for sync-at.bitfire.davdroid.addressbooks bitfire.at.davdroid/[email protected]

I think providing the ContentProviderClient is not responsibility of the BaseSyncWorker – the Syncers should acquire the required content provider client themself. The worker should just handle a possible error.

[rfc2822]

Looks like we don't (and didn't?) show a notification when the content provider can't be acquired. This can happen when the contacts or calendar permission is revoked (which can also happen automatically!) or the user disables the contacts storage app.

Steps to reproduce:

1. Set up DAVx5 with contacts and calendar sync.
2. Remove contacts/calendar permission.
3. Sync either from DAVx5 (which shows a warning in the UI, but it can't be seen when the user doesn't open DAVx5) or just wait for the next sync.
4. There's no notification that sync is broken.

Expected: There should be a notification.

As far as I have seen, there was no notification before this PR, too. Is that possible? 😄 Please check and then:

• If there is currently (before applying the PR) also no notification in this case, we don't have to handle the case in this PR. Instead add that information to Sync: re-factor error handling #887.
• If the is currently a notification in this case, this PR shouldn't make it worse, so we'd have to also show a notification when the PR is applied. Improving and refactoring sync error handling is then task of Sync: re-factor error handling #887.

(And we can also move the SyncAdapterServices.kt out of the .adapter package again, because we don't need a package if there's only one class in it.)

[sunkup]

There was no notification before this PR either :)

I have added the todo item in #887

[rfc2822]

There's still a merge conflict in SyncerTest

[sunkup]

There's still a merge conflict in SyncerTest

No, I don't think so. Not locally for me at least straight after pulling and not on the latest commit on github either. Also the tests should have failed then, no?

[rfc2822]

Hm this is how it looks here:

[sunkup]

Oh that one!