Rework integration of remote features for consistency between testing and live applications

[aaemnnosttv]

Feature Description

Remote features are currently set up unnecessarily late in the plugin bootstrapping which has led to at least one bug where a difference in behavior from our normal testing differed from pre-release testing with a remote-enabled feature. This can be addressed by setting up remote features as early as possible and breaking apart the bits which require running later.

See #8340 for a WIP POC.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Remote feature infrastructure (and its minimal dependencies) should be initialized and registered as early as possible, but not outside of Plugin::register
• The responsibilities of each part should be separated to allow for each to be set up as early as possible

Implementation Brief

• Use Rework integration of remote features #8340 POC as starting point. Shortly it covers:
• Update includes/Core/Util/Remote_Features.php:
  • Extend base Setting class, and keep only setting methods
  • Split the rest of the logic into classes:
    • includes/Core/Util/Remote_Features_Activation.php
      • Move googlesitekit_is_feature_enabled into the register method
      • Move here the get_features and filter_features methods
    • includes/Core/Util/Remote_Features_Sync.php
      • Move the cron logic here
• Update includes/Plugin.php
  • Instantiate Remote_Features_Activation class in the register method and hook into the admin_init to instantiate the Remote_Features_Sync. Invoke register method and cron scheduling, as well as on_change method.
• Wrap up the POC and fix failing tests

Test Coverage

• tests/phpunit/integration/Core/Util/Remote_FeaturesTest.php should be updated, as it only handles the Setting related methods. You can check tests/phpunit/integration/Core/User_Input/Site_Specific_AnswersTest.php for an example for tests
  • Extract the existing tests into the appropriate new test files, so they go into the Remote_Features_ActivationTest and Remote_Features_SyncTest classes.
• Update tests/phpunit/integration/PluginTest.php to verify the new changes on admin_init hook

QA Brief

• This issue changes how remote features are applied. It would be good to test general plugin behavior (eg smoke testing, module setup, etc.) as well as feature-flag-specific behavior, both enabled by the Tester and "manually" as if received via the proxy in the DB. I believe @mohitwp has done this before but ask @aaemnnosttv if you're not sure.

Changelog entry

• Ensure remote features are loaded as early as possible during plugin initialization.

[ivonac4]

@aaemnnosttv are you still planning to work on this one? If not, please unassign yourself.

[zutigrm]

Unassigning myself as I am not familiar enough with this feature and the priorities it would need to be split into

[tofumatt]

Removing QA:Eng since this QA should be a general plugin test with/without various feature flags enabled.

[mohitwp]

@aaemnnosttv In QAB, I don’t understand the phrase Feature flag enabled 'manually as if received via the proxy in the DB.' Can you please explain what this means? Does it refer to setting up Site Kit using the developer plugin? Thanks !

[aaemnnosttv]

Oh sorry @mohitwp, I just meant the same behavior whether the feature was enabled via the Tester or set in the database (as it would be for a live site). Does that make more sense?

[mohitwp]

QA Update ✅

• Tested on main environment.
• Smoke tested plugin.
• Verified all modules setup.
• Verified entity and main dashboard.
• Verified settings page.
• Verified Ad blocker functionality.
• Verified Key metrics functionality.
• Verified Enhanced measurement functionality.
• Verified audience segmentation.
• Verified modules when feature flag enabled by Tester plugin and or set in the database.
• No console errors are found.
• All functionalities working as expected.