Fix masterylog end timestamp issues

[rtibbles]

Summary

• Fixes bug and adds regression test to ensure the end_timestamp on masterylogs get properly updated after initialization
• Adds tests for and updates behaviour to ensure that our upgrade machinery can handle compound version ranges
• Adds upgrade function to remediate the masterylog end timestamp issues if the upgrade is from an affected Kolibri version
• Updates any masterlogs whose end timestamp is the same as the start timestamp, as would be the case for those affected by this bug
• Sets to the completion timestamp of the mastery log if it exists
• Otherwise set to the end timestamp of the most recent attempt
• Otherwise set to the end timestamp of the content summary log

References

Fixes #12855

Reviewer guidance

Are all three cases needed? Possible we could just check attempts and then content summary log.

…

[github-actions[bot]]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.18.0a0.dev0_git.4.gf255c976.pex
Windows Installer (EXE)	kolibri-0.18.0a0.dev0+git.4.gf255c976-windows-setup-unsigned.exe
Debian Package	kolibri_0.18.0a0.dev0+git.4.gf255c976-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.18.0a0.dev0+git.4.gf255c976.dmg
Android Package (APK)	kolibri-0.18.0a0.dev0+git.4.gf255c976-0.1.4-debug.apk
TAR file	kolibri-0.18.0a0.dev0+git.4.gf255c976.tar.gz
WHL file	kolibri-0.18.0a0.dev0+git.4.gf255c976-py2.py3-none-any.whl

[rtibbles]

The Django upgrade handling stuff might be a really interesting quick demo. Mostly curious about what parts of it are automagical and how - I went into this expecting it to be a part of a migration but seeing the upgrade.py it looks a lot more like a Django ™️ feature for handling upgrades.

It's a Kolibri ™️ feature for handling upgrades - mostly to do data migrations outside of the irritating straight jacket of the Django migration system - also because it's completely under our control, we can do non-Django operations in it, and also do the version control stuff specific to Kolibri.