Fix filtering of not applicable SCA checks using result filter

[Desvelao]

Description

This PR:

• Change the filter of not applicable SCA checks to use result filter instead of status
• Remove the status filter suggestion of the SCA checks search bar
• Sort the filters displayed in the search bar.
• Unify the SCA check result label in:
  • Module/Security configuration asssessment/Inventory policies table
  • Module/Security configuration asssessment/Inventory visualization legend
  • Module/Security configuration asssessment/Inventory/Policy checks table
  • Agents/:agent/overview SCA policies table

Issues Resolved

Closes #5027

Evidence

Unify SCA check result label name

Filter in the search bar

Suggestions in the search bar

Test

⚠️ Some tests require to mock the SCA check or using a Wazuh manager that has implemented the unification of status and result properties.

Patch for imposter:
wazuh-kibana-app-pr-5031-imposter.txt

The scenarios could use a Wazuh manger built from the [dev-sca-policy-checks-result](https:/wazuh/wazuh/tree/dev-sca-policy-checks-result) branch.

Scenario 1 The Not applicable kpi filters by result: not applicable in the SCA checks
Given a SCA policy with not applicable checks
When the user clicks on the Not applicable stat
Then a result: not applicable filter is added to the search bar
And the table should fetch the data whose SCA checks are not applicable and display them

Scenario 2 The SCA checks suggestions should not display the status filter key
When the user clicks on the search bar
Then the status filter should not be displayed

Scenario 3 The SCA checks filter keys should be sorted alphabetically
When the user clicks on the search bar
Then the filter keys should be sorted alphabetically

Scenario 4 The kpis in the SCA checks are labeled
When the user navigates to the SCA checks
Then the kpi that displays the checks that passed is labeled as Passed
And the kpi that displays the checks that failed is labeled as Failed
And the kpi that displays the checks that are not applicable is labeled as Not applicable

Scenario 5 The result for the checks displayed in the SCA checks table are labeled
When the user navigates to the SCA checks table
Then the check that passed is labeled as Passed
And the check that failed is labeled as Failed
And the check that didn't apply is labeled as Not applicable

Scenario 6 The result for the checks displayed in the SCA policies table are labeled
When the user navigates to the SCA policies table
Then the checks count that passed are labeled as Passed
And the checks count that failed are labeled as Failed
And the checks count that didn't apply are labeled as Not applicable

Scenario 7 The results for the checks displayed in the SCA policies visualization are labeled
When the user navigates to the SCA policies and sees the visualizations
Then the checks count that passed are labeled as Passed
And the checks count that failed are labeled as Failed
And the checks count that didn't apply are labeled as Not applicable

Scenario 8 The results for the checks displayed in the SCA policies table in the agent overview are labeled
When the user navigates to the agent overview and sees the SCA policies table
Then the checks count that passed are labeled as Passed
And the checks count that failed are labeled as Failed
And the checks count that didn't apply are labeled as Not applicable

Check List

• All tests pass
  • yarn test:jest
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[yenienserrano]

LGTM

Scenario 1 🟢

Scenario 2 🟢

Scenario 3 🟢

Scenario 4 🟢

Scenario 5 🟢

Scenario 6 🟢

Scenario 7 🟢

Scenario 8 🟢

[chantal-kelm]

CR: ✅
TEST: ✅

[chantal-kelm]

CR: ✅
TEST: ✅

[github-actions]

Code coverage (Jest)	%	values
Statements	8.72%	( 3225 / 36950 )
Branches	4.55%	( 1306 / 28685 )
Functions	7.62%	( 698 / 9160 )
Lines	8.79%	( 3110 / 35381 )

[github-actions]

The backport to 4.4-7.16 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.4-7.16 4.4-7.16
# Navigate to the new working tree
cd .worktrees/backport-4.4-7.16
# Create a new branch
git switch --create backport-5031-to-4.4-7.16
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 dd81bc669e6d2748a7b17a41b104557da339f327
# Push it to GitHub
git push --set-upstream origin backport-5031-to-4.4-7.16
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.4-7.16

Then, create a pull request where the base branch is 4.4-7.16 and the compare/head branch is backport-5031-to-4.4-7.16.

[github-actions]

The backport to 4.4-7.10 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.4-7.10 4.4-7.10
# Navigate to the new working tree
cd .worktrees/backport-4.4-7.10
# Create a new branch
git switch --create backport-5031-to-4.4-7.10
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 dd81bc669e6d2748a7b17a41b104557da339f327
# Push it to GitHub
git push --set-upstream origin backport-5031-to-4.4-7.10
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.4-7.10

Then, create a pull request where the base branch is 4.4-7.10 and the compare/head branch is backport-5031-to-4.4-7.10.