Add option to enable the v3 scheduler

[BrayanDSO]

Pull Request template

Purpose / Description

Help people test, and test and test and test and test all night long

Approach

• extract part of the logic of _loadScheduler() into CollectionHelper.isV3Enabled
• add a new experimental preference called "Use the v3 scheduler"
  • it's dependent on the new backend, i.e. the user can only enable it if the new backend is being used

How Has This Been Tested?

• Sync the collection
• Enable v3 on AnkiDroid -> sync -> see if it was enabled on another device
• Disable v3 on AnkiDroid -> sync -> see if it was disabled on another device
• Enable v3 on another device -> sync -> see if it was enabled on AnkiDroid
• Disable v3 on another device -> sync -> see if it was disabled on AnkiDroid

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[mikehardy]

I like this a lot, and I think it's near-perfect, just want a second look at the null handling as commented

[mikehardy]

should this be in a withCol { } ? just curious, it's col!! here, but below col? (but then col?.newBackend!! - the null handling just has me a bit worried

[BrayanDSO]

Very good question and I can't answer for sure. I haven't thought much about withCol, neither I grasp completely where we should use it, but I suppose it's on wherever possible.

I've tried to adress this on the last two commits and I'm gonna ask @dae if they are fine or if he could give me a direction on this

I'm definitely not sure if the runBlockingCatching use was correct, as it is used to configure the UI. Probably not.

[dae]

Ideally, all new code committed to the repo would use withCol, and ideally doing so in a launched task, so it doesn't block the UI like runBlockingCatching does. Integrating a launched task into some code paths may be tricky though, and it can require additional changes to avoid breaking unit tests if that path is tested, so it may be worth being pragmatic at the moment - allowing blocking calls if required, and not blocking a PR if there's already a bunch of surrounding code accessing the collection directly.

[BrayanDSO]

Okay, good to know. Used lanchCatchingTask. Thanks!

[mikehardy]

This looks much better to me! Thank you