Make sure to send mobile visit to saas warmup for OCI with a fresh install

[wordpressfan]

Description

Fixes #6752

Documentation

User documentation

For fresh installation or when the mobile cache settings are not set, we will consider it active by default.

Technical documentation

Here we set the default value sent to $this->options->get to be 1.

Type of change

Delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue).

New dependencies

List any new dependencies that are required for this change.

Risks

Can't think of any risk here.

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for cb820e91	✅ 100.00% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (cb820e9)	Report Missing	Report Missing	Report Missing
Head commit (7a0da6f)	37336	14518	38.88%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6753)	1	1	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

---

_{🚀 Don’t miss a bit, follow what’s new on Codacy.}

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[wordpressfan]

For @wp-media/qa-team you can use the following snippet to completely disable mobile cache options to be used to validate the mentioned AC:

add_filter( 'pre_get_rocket_option_cache_mobile', '__return_false' );
add_filter( 'pre_get_rocket_option_do_caching_mobile_files', '__return_false' );

[MathieuLamiot]

@wordpressfan A quick feedback, not blocking for the PR but more food for thought, to improve: we would lack integration tests that capture the AC better. Currently, all tests involving sendToSaas() seem to mock options->get so we test that is_mobile behaves as expected when options are set to 0 or 1.
Unfortunately, I think there are no tests on the behavior we are trying to achieve here. We would need a test that ensures is_mobile (or sendToSaaS) behaves as expected when no callbacks to get_rocket_option_cache_mobile and get_rocket_option_do_caching_mobile_files (hence, mocking a fresh install). That would require a test that does not mock options->get itself.
Do you see what I mean? It might not be straightforward to implement, and I think manual test can do for now to avoid blocking the PR. But it would be good to keep in mind the approach of having built-in tests to validate the ACs.

[wordpressfan]

Totally agree with you @MathieuLamiot

[Khadreal]

LGTM

[Mai-Saad]

Test summary https://wp-media.slack.com/archives/CUT7FLHF1/p1719910569290519?thread_ts=1719832961.594679&cid=CUT7FLHF1 . if newlabs state with a fresh install is considered an edge case and not a priority for now then we can merge with the following notes:
1- Adding the home page to DB correctly is pending 6746 (out of scope)
2- Sometimes AS won't create warmup actions thus nothing is sent to metabase nor DB (out of scope)