Limit the displayed review count to 99999 instead of 1000

[Ekleog]

Purpose / Description

Unlimit the displayed review counts, by limiting them to 99999 instead of 1000, as per #5197 (comment)

Fixes

Fixes #5092, #5197 and #5322

Approach

I don't know Ankidroid's architecture, and at parts of what I've seen it sounds like it aims to be almost a transcription of the python code, so I've changed as little as possible.

Note that here I think I change the constants limiting both the study counters and the deck list counters. Potentially the slowdown caused by counting all the full deck counters will be a problem, in which case it should be possible to revert the Sched{,V2}.java parts of it, I think (or roll them back to “just” 9999, maybe?). This would unfix #5092 and #5197, though, but keep #5322 fixed.

How Has This Been Tested?

This is the first time I attempt to contribute to an android project, so it has not actually been tested. Given what the code around it looks like, I'm relatively confident it's OK-ish, though.

Learning (optional, can help others)

Grep'd through the source code for 1000, looked at all occurrences: rg -w 1000 | rg -v '............................................................................................................................................................................................................................' > 1000-occurrences && vim 1000-occurrences

Checklist

• You have not changed whitespace unnecessarily (it makes diffs hard to read)
• You have a descriptive commit message with a short title (first line, max 50 chars).
• Your code follows the style of the project (e.g. never omit braces in if statements)
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code

[Ekleog]

(I'm pretty sure the travis failure is unrelated to this PR, as it looks like a missing dependency in the .travis.yml -- I feel forced to suggest using nix for building ankidroid, as it can provide perfectly reproducible builds that should make it impossible that something like this happen when using it, but feel free to ignore me :))

[mikehardy]

Yeah the CI failure is unrelated. How apropos that your first android PR would have a CI failure (testing Android in CI is notoriously painful because of lack of nested virtualization in CI envs). But it relying on Travis' CI images to remain stable has been a safe bet for a couple years vs the pain of taking a raw image in their env and keeping track of my own dependencies. And this looks like a failure in their image to have a fundamental android dev tool, which isn't something that should happen. I'll dig into it in a bit

[mikehardy]

Underlying operating system changed from debian trusty to xenial per a long-term migration on Travis' part. Our builds were 100% on trusty and 0% on xenial when they migrated our project a couple days ago apparently. They specify in their docs that they only support android on trusty right now, so rather than not specifying and accepting the default we have to specify dist: trusty and we're good

#5327 fixed it - if you rebase from master and force push your branch out, it should be a clean commit on a working CI config then I can look at the PR for real...

[Ekleog]

Thank you! Rebased and force-pushed :)

[Ekleog]

(And I can confirm that the tests passed this time)