SyncAdapterServices: Use a coroutine scope to cancel waiting on framework request

[rfc2822]

Purpose

Currently, the SyncAdapterServices (handles syncs initiated by the Android sync framework) runs a sync job and waits for the result, but does not abort waiting when the sync framework requests cancellation.

The finished variable which was made for this is not evaluated.

Note that "cancellation" in this context shall never cancel the actual sync worker, but only the sync framework job (that waits for the worker to finish).

Short description

Now we use a coroutine scope instead.

• When the sync completes in time, collect is cancelled, waitJob finishes and waitJob.join() just returns.
• When the framework sync is cancelled by the framework (onSyncCanceled), waitScope is cancelled, thus waitJob is cancelled, and waitJob.join() just returns.
• When the framework sync is cancelled by timeout, withTimeout cancels and a log message is printed.

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.

[sunkup]

Looks really good. Seems to work fine as well. I wonder a bit though: Should the tests not contain some assert or verify calls? Or are they purely meant to capture the implementation state, such that when it changes a test will fail?

[rfc2822]

Looks really good. Seems to work fine as well. I wonder a bit though: Should the tests not contain some assert or verify calls? Or are they purely meant to capture the implementation state, such that when it changes a test will fail?

The key is the Timeout rule. If something goes wrong in the tests, they will for instance wait 60 seconds to unblock the wait process, but until then the timeout rule has triggered and marked the test as failed.

[sunkup]

Looks really good. Seems to work fine as well. I wonder a bit though: Should the tests not contain some assert or verify calls? Or are they purely meant to capture the implementation state, such that when it changes a test will fail?

The key is the Timeout rule. If something goes wrong in the tests, they will for instance wait 60 seconds to unblock the wait process, but until then the timeout rule has triggered and marked the test as failed.

Smart :)