Jetpack Plugins: Use real-time Manage module activation status

[tyxla]

This PR fixes #8404, where Manage module is incorrectly being considered deactivated in certain cases. The PR suggests using the real-time activation status of the Manage module instead of the one we have from the latest sync.

This will require some more testing (cc @lancewillett), as the issue was difficult to reproduce in the first place. I was lucky to reproduce it today, which helped in fixing it.

It's worth to mention that the plugins main component requires some refactor in order to approach this issue the best way (e.g. avoid repetition of rendering the QueryJetpackModules query component), but let's leave that for another PR, and get this long-standing issue fixed.

To test:

• Let $site is a Jetpack site, and $plugin is a plugin of your choice that's active on that site.
• Deactivate the Manage module for that site.
• Go to /plugins/$site.
• Verify you're receiving the "Manage not activated" error.
• Activate the Manage module for that site.
• Refresh /plugins/$site.
• Verify you see the placeholder while loading.
• Verify you see the plugins list after sites and modules have loaded.
• Deactivate the Manage module for that site.
• Go to /plugin/$plugin/$site.
• Verify you're receiving the "Manage not activated" error.
• Activate the Manage module for that site.
• Refresh /plugins/$plugin/$site.
• Verify you see the placeholder while loading.
• Verify you see the plugin page after sites and modules have loaded.

[matticbot]

Test live: https://calypso.live/?branch=fix/jetpack-plugins-cant-enable-manage-module

[oskosk]

There's still some weird state if you do the following

1. Disable manage (using JP 4.7.1) you can still disable it by searching for Manage in the Settings search input on the Admin Page
2. Enable again
3. Disable again and visit Calypso's /plugins/your-site.
4. The main component will receive the real time data but the sub components still think the module is inactive. (See screenshot)

[oskosk]

Two other observations:

1. By using this mechanism, we lose somehow the effect of the SITES_RECEIVE action which is consequence of a polling of the site's data. This is why you can see, related to my previous comment, that eventually the list of plugins gets enabled again after some time if the polling sets manage to enabled in the sites state.
2. There's an undesired flash of content when Calypso is fetching the REST API. As the default state is calculated as inactive, the "enable manage" EmptyContent component is shown in the transition. See gif:

While working on this, I came up with this proposed refactor to rearrange a little bit how we react to a loading state. Maybe it comes in handy as reference for this PR.

[tyxla]

@oskosk thanks for the review, good catches there!

I've addressed your observations, could you have another look?

[enejb]

Instead of relying on fetching the active modules data could we used the current active modules that we get from /me/sites endpoint?

[oskosk]

@enejb, the code originally uses the data coming from /me/sites, but this PR was trying to circumvent some weird behaviour that was disallowing us to rely on the active modules data that was coming with /me/sites.

The data there reflected that .com was not aware of some of the actions while we were trying to activate/deactivate some modules frequently.

A few hours ago, @lezama addressed this issue in .com, so it's likely that this PR will be updated to reflect that.

More context about the fix is provided in p7rcWF-l0-p2.

[tyxla]

This one needs to be updated as @oskosk specified. Will take care of it soon. Thanks @lezama for taking care of the sync issue 🙇

[tyxla]

This PR is no longer necessary, the fix that was described in p7rcWF-l0-p2 addresses it. Closing.