fix: refresh course structure on Android

[edschema]

Description

Fixes a course-refresh issue on Android. When the app asked to refresh course structure while online, it could return the first saved copy and stop before making a new request. That saved copy can be out of date. iOS already makes a fresh request in this situation; this PR implements what iOS currently does for course refresh requests.

With this PR, when a caller explicitly asks for a refresh and the app is online, Android sends a Cache-Control: no-cache request. A saved response must be checked before it can be reused. This request is separate from ordinary course loading. An explicit refresh while offline still reads only saved data. Ordinary course loading remains cache first.

This better aligns Android's course-refresh behavior with iOS. It is also an Android prerequisite for later course-routing work. The routing change will be a separate PR after this one merges. Both PRs must land before mobile Inbox can be enabled.

Out of Scope

This PR does not add Inbox or routing behavior. It does not change the server API, database schema, database migrations, or the caching behavior for status, dates, progress, or enrollment.

Change Log

• Send only explicit online refreshes through the new Cache-Control: no-cache request path.
• Allow matching refresh requests to share one request, but never let a refresh reuse an ordinary cache-first request.
• Keep an older request from changing the current course session after the learner leaves and reopens a course.
• Ensure an older cache-first result does not replace a newer refreshed course structure.
• Clarify the code comments that explain request cancellation, course sessions, and database writes.
• Add 12 focused regression tests covering refresh behavior, request sharing, persistence ordering, and course-session isolation.

Notes

An explicit online refresh that fails does not silently return older course structure. An explicit offline refresh continues to use saved data only.

A refresh cannot reuse an ordinary course-loading request because the two requests have different cache rules.

The existing Dates caller that asks for a refresh benefits from this change. No Dates code changes are included.

CourseInteractor now checks network availability before choosing the refresh path. Its public interface and the course API contract are unchanged.

Tests Done

Local test cleanup, verified at 9282e9a:

• 10 tests in CourseRepositoryFreshTest, covering real interactor/repository behavior, online and offline loading, failure propagation, request isolation and sharing, delayed database reads, and session ordering.
• 2 tests in CoalescingCacheTest, covering generation-safe cache writes and cancellation/replacement ordering.
• :course:testDevelopDebugUnitTest: 75 tests passed.
• detektAll passed.
• git diff --check passed.

Earlier validation of the unchanged production implementation, not rerun for the test cleanup:

• :app:assembleDevelopDebug passed.
• Pixel checks for online refresh, offline use of saved data, and a controlled changed course-structure response.
• Android lint ran and reported only documented pre-existing issues in unrelated files.

AI Assistance

AI tools were used to aid diagnosis, planning, implementation, testing, and review. All work was checked and reviewed.

[openedx-webhooks]

Thanks for the pull request, @edschema!

This repository is currently maintained by @openedx/openedx-mobile-maintainers.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.