This commit corrects the following bug:
* Create a note N in an empty deck D of type basic (reverse), with
only some back, no front. Only card 2 will be generated.
* Edit the note, add a front. Card 1 will be generated.
* In the main window, try to learn deck D. In anki, currently, you'll
see Card 2 first. According to the manual (and to my common sens),
it should be Card 1 first.
This commit correct this bug, and ensure that new cards are seen
according to their order, and not to their creation date.
- move checking code out of the schedulers and into the deck manager
- ensure we can fix the problem in one loop - the previous recursive
approach could lead to stack overflows if the top level of a large
deck tree was missing. this was also the cause of the sqlite
'interrupted' error that some users were seeing
- cap kept for the deck list, as we need to calculate it for multiple
decks
- v2 sched can calculate review limit faster, as it doesn't have to
check each deck separately
- filtered deck cap is same as in interface
- as this will be deployed on ankiweb, beta clients will need to update
or risk getting sanity check errors when syncing with high due counts
When studying, the learning count now indicates the number of
learning cards due within the learn ahead limit, instead of the total
number of learning steps required to complete that day.
Also fix the ineffective limit clauses in the learning counts.
We can't preserve the original queues when in preview mode, as
otherwise the due counts report the remaining steps of cards in
the learning queue, instead of just 1.
Rather than the rather complicated approach of making the learning and
deck list code aware of the current mode we're in, preview mode moves
all cards to the review queue when the filtered deck is built - just as
cards are moved to the new queue in Anki 2.0.x. The reason for the
review queue is that users were frequently confused when cards appeared
as new - hopefully this is slightly less confusing.
