Task scheduling updates for Android

[rtibbles]

Summary

• Moves the marking of a job as running inside the job execute method so that it happens independent of task runner
• Make the rescheduling of a task after it has completed (either for repeat or retry behaviour) separate from the updating of the status
• Most importantly, uses the schedule method to reschedule the new task, rather than the update methods, so that schedule hooks are called
• Adds some reusable validation functions for commonly used scheduling arguments
• Move Priority enum to constants to avoid a circular import
• Fixes unnoticed bug in enqueue_if_not that failed to pass through passed in arguments.
• Updates how retry_in works to defer setting until after the job has completed, and then passing the new arguments to the reschedule job - allows the scheduling to be deferred until task completion, and to allow the retry_in behaviour to be used more liberally

References

Should resolve Android syncing issues that were caused by the combination of the existing retry_in behaviour (which set repeat to 1) and the update hooks that pass the orm_job to the update hooks after the orm_job has been modified (so repeat would be 0, and no repeat would be scheduled by the Android hook).

Does this by making sure that all job scheduling events trigger the schedule hook, and that the update hook is only for processing state updates. This feels like it makes a lot more sense anyway!

Reviewer guidance

The APK generated here will probably mostly work as it is - but I have some correlated changes for Android which I will open in a PR on the Android repo. I will also build an APK from this PR with those changes for testing.

Further testing on Android has shown some issues, but not related to this PR, it seems to have uncovered some weirdness that I hadn't previously observed in properly reading the job_id within the WorkManager context. This PR can be reviewed independently.

@pcenov and @radinamatic please make sure that these changes cause no regressions in existing syncing behaviour.

---

Testing checklist

• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Critical and brittle code paths are covered by unit tests

PR process

• PR has the correct target branch and milestone
• PR has 'needs review' or 'work-in-progress' label
• If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• If this is an important user-facing change, PR or related issue has a 'changelog' label
• If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.16.0b6.dev0_git.321.g46cf7f2e.pex
Windows Installer (EXE)	kolibri-0.16.0b6.dev0+git.321.g46cf7f2e-unsigned.exe
Debian Package	kolibri_0.16.0b6.dev0+git.321.g46cf7f2e-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.16.0b6.dev0+git.321.g46cf7f2e-0.3.0.dmg
Android Package (APK)	kolibri-0.16.0b6.dev0+git.321.g46cf7f2e-0.1.0-debug.apk
TAR file	kolibri-0.16.0b6.dev0+git.321.g46cf7f2e.tar.gz
WHL file	kolibri-0.16.0b6.dev0+git.321.g46cf7f2e-py2.py3-none-any.whl

[pcenov]

Hi @rtibbles - no regressions observed in the existing syncing behaviour while manually testing today on several devices.
The Android app behaviour is also unchanged (not syncing after the initial sync) - but as you mentioned this will be tested separately when you prepare a new Android build for that.

[marcellamaki]

code read through looks okay to me