Fix #4632, #3779: Add support for checkpoint upgrading

[BenHenning]

Explanation

Fixes #4632
Fixes #3779

Adds support for upgrading checkpoints to support the latest versions of explorations if the checkpoint was saved for an older version, in cases where it's very likely reasonable to upgrade the checkpoints. The methodology applied is to simulate "replaying" the full lesson using the past answers that were submitted in the checkpointing, and verifying that the same outcome would more or less be achieved by ensuring:

• The content IDs for received feedback haven't changed (but the HTML might, e.g. for typos).
• The destination of a state hasn't changed.
• The pending & all completed states still exist.

The cases that currently can't be handled (but may be reasonable to in the future):

• State renaming (these are treated as failures).
• Reconstituting a compatible hint/solution state (the state is just reset for now so the user can re-trigger the hints if they get stuck after returning to the lesson).

As part of testing this:

• A bunch of new assets were introduced to directly demonstrate upgrading flows that lead to both compatibilities and incompatibilities (these were generated).
• A fake ExplorationRetriever needed to be introduced in order to support proxying exploration loading (so that newer versions can be force-loaded). This required splitting the existing ExplorationRetriever into an interface & implementation.
• ExplorationStorageModule has been moved one package up for better organization (which led to a bunch of other files being changed).
• Test-only checkpoint database storage sizes have been 150 bytes in all related tests, so this has been made as the test-specific constant in the new ExplorationStorageTestModule.

Separately, ExplorationRetriever was updated to mostly force background thread interaction by using a suspend method for actual exploration loading (which led to some small test changes).

#3779 was also fixed (since I was changing this code, anyway) by returning a default details object instead of failing whenever a checkpoint can't be found for a given exploration. Note that no test was added for this solution since doing so would be a bit painful (as it requires loading and verifying an exploration at the activity level where a bunch of the lower-level tools from StateFragment{Local}Test aren't available), and the failure case here is something that will definitely be caught by e2e tests so the risk is low for a serious regression.

Essential Checklist

• The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• Any changes to scripts/assets files have their rationale included in the PR explanation.
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio (reference).
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers (reference).

For UI-specific PRs only

While this PR does affect UI flows for checkpoints, I'm opting to not include a walkthrough since it's difficult and time consuming to simulate the local upgrade flow. We'll be testing this specially during manual QA testing for this release to ensure it works as expected.

Similarly, app module tests haven't changed in a major way so I'm skipping showing Espresso results here. The Robolectric tests results ought to be a sufficiently good proxy for correctness.

[BenHenning]

@seanlip PTAL. As an FYI I have also self-reviewed the whole PR.

[seanlip]

LGTM, but with the disclaimer that I've only been able to take a cursory look and didn't see anything obviously wrong (but I can't certify correctness). Thanks!

[BenHenning]

Merging this without @rt4914's approval since it's release blocking.