This commit (temporarily) allows tasks with floating start or due and absolute until part in the RRULE and vice versa.
Apparently such tasks exist and we didn't validate this condition. So for now we tolerate this issue until we can be sure
the database won't contain such tasks.

Apparently there are tasks which have a recurrence rule but neither a dtstart nor a due date. This caused an NPE. By treating such tasks as non-recurring this should be fixed.

Recurring tasks may specify a dtstart and due date (instead of a duration). If the task was an all-day task, we may have tried to add a duration derived from the difference between start and due.
The result was a non-all-day duration (although in most cases being a multiple of 24h) and adding this to an all-day date resulted in an error. It's fixed by converting the duration into a proper
all-day duration.

Updates TaskProvider to skip updates which don't change any value. In such case no database operation is necessary and no notifications will be triggered.

Upon moving a task to a new list, it's not just moved, but a deleted copy is left behind in the old list, so sync adapters can take note of the removal in the old list.
This commit fixes the creation of the deleted instance. The code tried to create instance columns in the task table, which failed and caused the deleted instance to be missing.

This commit ensures that the TaskAdapter which is used to insert the deleted instance does not contain instance values.

It's no longer necessary to update all values which affect recurrence in the same update. The provider can handle updates of individual fields.

This commit adds initial recurrence support in that recurring instances are handled correctly when instances are edited or deleted.
In order to support this, the UI now operates on the Instances table rather then the tasks table. The instances table now supports deletes, and updates like the tasks table with the difference that all these operations only affect the specific instance that's addressed. All the operations on the instances table are converted into operations on a task by creating exception instances and RDATEs or EXDATEs.

Inserting instances is currently not possible because only a fixed number of instances are expanded. This means an instance inserted beyond the expansion window would still not show up in the instances table.
See https://github.com/dmfs/opentasks/issues/741

There is still room for improvement in that we could split of completed tasks and modify recurrence rules when deleting instances from the start or end of the series. That's left to future updates.
Also there is no UI yet to create or edit recurrence properties itself.

At present there is only one upcoming instance expanded, so you can only see the "current" instance (and all completed ones). This may/will change in future but may require some UI changes as well.

In order to support this commit a number of tests have been implemented which test creating and altering recurring instances.

Currently an exception is created when a recurring instance is modified which wasn't an exception before. This approach is RFC 5545 compliant but not supported by Apple clients. This will be fixed in future updates.

Since Android 8 it's not possible to listen to implicit broadcasts anymore when the reciever is declared in the AndroidManifest.xml.
In a previous commit we disabled sending out broadcasts to other apps. This caused some trouble.
For new we hard code 3rd party receiver package names in a resource array. This is supposed to be changed later on, see #824.

When a task is modified we compare the current notification state to the new one and update the notification if necessary.

In certain cases we remove the notification now:

* the task was unpinned (by the sync adapter)
* the start of a task has been postponed
* the due date of a task has been postponed
* a task has been completed

This sets a "notification cancelled" intent which removes the persisted entry when the notification is swiped away.

* update jems to 1.22
* update contentpal to 0.5
* update lib-recur to 0.11.2
* update color-picker to 1.3
* update bolts to 0.1
* fix dependency scopes
* update `Diff` usage to account for correct Comparator logic
* replace some classes with their upstream counterparts

* Bump support_lib_version from 26.1.0 to 28.0.0
* Bump support_test_runner_version from 0.5 to 1.0.2
* Bump mockito-core from 2.10.0 to 2.27.0
* Migrate to AndroidX
* Bump appcompat from 1.0.0 to 1.0.2
* Bump androidx_test_runner_version from 1.1.0 to 1.1.1

* Bump AGP to 3.4.1, gradle to 5.1.1

* Fix lint error

The cause of issue #793 is actually unknown but this once could be a good candidate. In few cases the database might already be on version 20 but the version column had not been created.
This might be caused by having the beta version installed before (which already had a version 20, but without the column).

This fix always checks if the version column already exists and creates it otherwise.

Version codes of releases (master builds) are now always higher than version codes of beta builds (feature branches).
This ensures we can always update the production release.

* Introduce composable TaskAction handlers
* Implement TaskActions required for feature parity with the old service
* Clean up old notification services

This commit adds a read-only task VERSION column which is incremented upon any update or a task (including sync-adapter updates).

The column serves two purposes:

* safe transactions by asserting a specific version before updating a task
* quick detection if a specific task has been modified

The former could be used by sync-adapters to ensure a task has not been updated while being synced.
Notifications will make use of the latter to avoid unnecessary updates of task notifications for unchanged tasks.

Reduces/removes lag while background sync (#738)
Also avoids reloading widget multiple times after a change to a task.

In addition to just updating the ContentPal version this also replaces usages of deprecated jems classes.

In order to evaluate the provider performance and its impact on the UX this commit adds some simple profiling statments which measure the execution time of certain operations and write them to logcat.
Hopefully this helps a but to detect slow operations and bottlenecks.

Instead of creating the details view lazily when the task is loaded, we create it in `onCreateView` so it always exist. Hopefully this fixes #755, but since the actual reason is still unclear we can't be sure. In any case the details view needs a refactoring which reduces mutable state and makes it more robust.

Under certain conditions the task details fragment was about to be replaced after the fragment manager already saved its state. This caused a crash. This change checks whether the state has already been saved before committing the transaction.

The previous implementation tried to use the CONFLICT_IGNORE policy when inserting new ngrams and was falling back to a query in case it failed to find the id of the exiting ngram. This was very slow because it meant an expensive query for every ngram to insert.

The new solution goes over the existing ngrams and only inserts the ones which don't exist in the database. Similarily the ngram relations table is not cleared for the particular task, instead the existing ngrams are loaded and only new relations are inserted and obsolete relations are removed.

* fix recursive updateNotification calls
* replace compile with implementation

This commit removes the changelog we've sent with the ProviderChanged Broadcast. It's never really been used so far but may blow the IPC buffer size limit.
We need to find a better way to communicate changes efficiently to plugins once we support them. It's not a pressing concern though.

The regular expression for the internal track didn't cover a revision descirption like `1.1.16-dirty` which is a release commit with changes.
The proposed fix makes the part between the version number and `-dirty` optional.

This commit adds a workaround for sync apps which don't grant account visibility to OpenTasks. If a task list is inserted which belongs to an account which we can't see, the app asks for permission to see the account.
The `GET_ACCOUNTS` permission is no longer used on Android 8+ and the request for that permission will no longer be shown when the app starts.

Update the publish configuration to derive the publishing track form the version number.