[Security Solution] Replace EUI filtering with custom in-memory filtering in Add Rules and Rule Upgrade tables

[jpdjere]

Summary

1. Replaces the EUI out-of-the-box filtering by rule name and tags used in the initial implementation with custom in-memory filtering.

This aligns the look-and-feel of the Rules Management table with the new Add Elastic Rules and Rule Upgrades table

2. Adds a CTA in the Add Elastic RUles table when all rules have been installed, that navigates the user back to the Rules Management table.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[xcrzx]

Thanks for the PR, @jpdjere! 👍 I've run some local tests and everything is working as expected. I've noted a few minor suggestions for further enhancements, but none of them are critical.

[xcrzx]

Filtering is a synchronous operation that doesn't initiate HTTP requests. Therefore, starting an APM transaction just before this operation might inadvertently capture any unrelated HTTP requests that follow. I suggest we remove these transactions to avoid capturing irrelevant data.

[jpdjere]

Thanks! fixing this

[xcrzx]

I'm wondering whether this isEqual check is necessary. How frequently is the callback invoked with identical tags?

[xcrzx]

Nit: according to the provider code, selectedTags should never be undefined. Can we adjust our types to reflect that?

[jpdjere]

Yes, thanks. Fixed the types here 👍

[xcrzx]

Is it possible for us to reuse the rule filtering method from the add rule context here?

[jpdjere]

So I actually wanted to create a reusable hook for both adding and upgrading rules cause the filtering logic is the same. The problem is that the type of rules is slightly different in these two cases, because in the install case, all the properties of the rule (that I need to filter on) are top-level properties (i.e name and tags).

In the upgrade case, those are nested within rule:

export interface RuleUpgradeInfoForReview {
  id: RuleObjectId;
  rule_id: RuleSignatureId;
  rule: DiffableRule;
  diff: PartialRuleDiff;
  revision: number;
}

So I tried making it generic for both like:

export const useFilterPrebuiltRulesToInstallOrUpgrade = ({
  rules,
  filterOptions,
}: {
  rules: RuleInstallationInfoForReview[] | Array<RuleUpgradeInfoForReview['rule']>;
  filterOptions: AddOrUpgradePrebuiltRulesTableFilterOptions;
}) => {
  ...

but that means that the Rule Upgrade table will be populated by DiffableRule-type objects instead of RuleUpgradeInfoForReview, and that means additional changes among the context, which I think we don't want just to make this reusable.

I'd like to discuss this with you anyways to understand what are you thinking, but I'd rather merge this PR as is with two separate hooks and refactor next week after FF.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: bc0c631

Failed CI Steps

• Security Solution Tests #7

Test Failures

• [job] [logs] Security Solution Tests #7 / Prebuilt rules Actions with prebuilt rules Rules table "before each" hook for "Allows to delete all rules at once"

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	4188	4193	+5

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	10.9MB	10.9MB	+3.9KB

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	13	15	+2
securitySolution	411	415	+4
total			+6

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	14	16	+2
securitySolution	494	498	+4
total			+6

History

• 💔 Build #135993 failed e09b684
• 💔 Build #135904 failed e332470
• 💔 Build #135892 failed 7fef3a3
• 💔 Build #135772 failed 236bbaf
• 💛 Build #135279 was flaky f5f14a4

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @jpdjere