Protect: Refactor useProtectData hook

[nateweller]

The intention of this PR is to enable the ability to access assorted threat counts, ultimately to disable status filters that have no related threats under the current selected category.

Also improves performance and usability of the hook.

Proposed changes:

• Moves all filtering of threat data to the useProtectData() hook.
• Updates the useProtectData() hook to use a single memo-ized loop to generate and filter all threats in one go.
• Adds counts property to useProtectData() hook, which tracks the amount of total and currently filtered threats across categories.
• Consolidates core, plugins, themes, files, and database properties into a threats property in useProtectData()'s return value.
• Updates the application based on changes to the hook.
• Disables the threat status filter buttons when no threats are available for the button's related filter.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

N/A

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Smoke test the scanner view in Jetpack Protect - start with a blank JN site, free plan, and work your way to a paid plan with threats both active and in history.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• 🔴 Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

🔴 Action required: Please add missing changelog entries for the following projects: projects/plugins/protect

Use the Jetpack CLI tool to generate changelog entries by running the following command: jetpack changelog add.
Guidelines: /docs/writing-a-good-changelog-entry.md

---

Once your PR is ready for review, check one last time that all required checks appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team Review" label and ask someone from your team review the code. Once reviewed, it can then be merged.
If you need an extra review from someone familiar with the codebase, you can update the labels from "[Status] Needs Team Review" to "[Status] Needs Review", and in that case Jetpack Approvers will do a final review of your PR.

---

Protect plugin:

• Next scheduled release: August 12, 2024.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[dkmyta]

On a fresh JT instance, without an upgrade, I can see that the initial Protect status report has been generated (properly set in the jetpackProtectInitialState var, JPDB, and in the jetpack_protect_status option), however, the Summary and ThreatsList components are empty:

Also wanted to note as it may be related to the change, the Scan UI was initially in an error state briefly before entering the scanning state.

[nateweller]

Looks like the issue is that the hook is now only providing the extensions that have threats, I will fix that up.

The flash of the error state appears to be on the project branch, will make a PR or issue for that as well.

[nateweller]

@dkmyta PR has been updated with a fix 👍

179e916

[dkmyta]

Code is clean and initial testing in a functioning environment shows it works.

I noticed something though that may be related to the current updates or may be more related to the prior addition of scanError selector and related adjustments. Manually setting the error var in useProtectData and visiting the ScanHistoryRoute component displays the ErrorScreen. Similarly, setting the scanError selector to return an error works. However, when simulating an actual error (for example updating my hosts file to point at public-api.wordpress.com but not running my sandbox to make wpcom requests fail provides for some unexpected results) first the ScanRoute component displays an empty list, with some relevant data missing:

Then shortly after (likely after the first status poll) the error display:

The ScanHistoryRoute performs similarly. I can see in both cases that the status and scanHistory initial state variables are populated correctly with error details so it would seem this maybe be more related to the frontend handling of such data.

Perhaps this is not the best way to generate an actual error but I think it does uncover that there is an issue.

[dkmyta]

Perhaps not specific to these changes, but similar to the issue with the filters routes, we'll need to redirect #/scan/history and /ignored or /fixed to #/scan if a user does not have an upgrade. Currently, visiting these routes without a paid plan is possible, the page is blank and we're hit with a bunch of console errors attempting to access properties of undefined (threats).

Interestingly enough, we do have a block for this in ScanHistoryRoute, but it doesn't seem to apply I suppose because the error takes precedence. Looks like it comes down to the fact that we still attempt to use scanHistory data (even though its set to false when ! hasRequiredPlan) in useProtectData on line 32 here:

	const { counts, results, error, lastChecked, hasUncheckedItems } = useMemo( () => {
		// This hook can provide data from two sources: the current scan or the scan history.
		const data = sourceType === 'history' ? { ...scanHistory } : { ...status };

[nateweller]

@dkmyta Added a PaidPlanGate component that we can wrap around any route that requires a plan: ea79065

[dkmyta]

Can this scenario ever occur on its own or will scanInProgress always be set when statusIsFetching is? If it can occur, then I think we need to update the display, as it is currently:

[dkmyta]

Looking good!