[Security Solution] Add Threat Match rule specific editable fields

[maximpn]

Partially addresses: #171520

Summary

This PR adds is built on top of #193828 and #196948 and adds the following editable components for Threat Match rule type

• threat_index
• threat_query
• threat_mapping
• threat_indicator_path
• threat_language threat_language was merged with threat_query

Details

This PR make a set of changes to make existing Threat Match form fields easily reusable as editable components and type safe when used in forms. In particular the following was done

• Fixes a bug blocking Threat Match rules upgrading
• Existing functionality was refactored to have reusable self-contained editable components for threat_index, threat_query, threat_mapping and threat_indicator_path rule fields
• threat_language was removed since query type is included in threat_query field and can be edited with Query Bar
• threat mapping input was split into separate component for individual fields to be reused
• ThreatMatchComponent was refactored to be a controlled component instead of uncontrolled
  ThreatMatchComponent has a feature preventing users removing the single last entry. Instead deleting the last entry the delete button clears inputs. That functionality didn't work properly in Prebuilt Rule Customization workflow and rule creation/editing forms after creating a reusable ThreatMappingEdit component. Instead of trying to find a tricky fix ThreatMatchComponent was refactored to remove internal state. The feature preventing users removing the single last entry was reimplemented in ThreatMappingEdit component.
• Fixes a bug reproducible in main where validation errors duplicated described in a comment
• Fixes a bug reproducible in main allowing to save unknown source indices or indicator indices fields described in a comment

How to test

• Ensure the prebuiltRulesCustomizationEnabled feature flag is enabled
• Allow internal APIs via adding server.restrictInternalApis: false to kibana.dev.yaml
• Clear Elasticsearch data
• Run Elasticsearch and Kibana locally (do not open Kibana in a web browser)
• Install an outdated version of the security_detection_engine Fleet package

curl -X POST --user elastic:changeme  -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.14.1

• Install prebuilt rules

curl -X POST --user elastic:changeme  -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 1" -d '{"mode":"ALL_RULES"}' http://localhost:5601/kbn/internal/detection_engine/prebuilt_rules/installation/_perform

• Open a threat_match rule for editing. For example Threat Intel Hash Indicator Match with rule_id aab184d3-72b3-4639-b242-6597c99d8bca.

• Edit Indicator index patterns, Indicator index query and/or Indicator filters, Indicator mapping and Indicator prefix override fields

• Open Detection Rules (SIEM) Page -> Rule Updates -> click on Threat Intel Hash Indicator Match rule -> expand each Threat Match rule type specific field -> press Edit button

Screenshots

Threat Match Query edit component

Threat Match Index edit component

Threat Match Mapping edit component

Threat Match Indicator Path edit component

Threat Match Mapping unknown field names validation warnings

[elasticmachine]

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

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[vitaliidm]

I have found few issues and left some comments, mostly questions and suggestions.
Will continue testing

[xcrzx]

I don’t have any changes in the filters field, but the diff shows some empty meta.alias fields that it thinks should be removed:

What is the meta field, and should it even be part of the diff calculation?

cc @dplumlee This seems similar to the issue we recently had with the schedule and threat fields.

[xcrzx]

The incorrect final field version has been selected. I have modifications to the field, so in this case, we should pre-select the current version and preserve all user modifications instead of removing them.

[maximpn]

@vitaliidm

Thanks for you ideas! I think option 2 is the best for now. I integrated your idea in the implementation. Could you have a look?

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 6639706

Failed CI Steps

• FTR Configs #9

Test Failures

• [job] [logs] FTR Configs #9 / Rules Management - Rule import export API @ess @serverless @skipInServerlessMKI import_rules importing rules with an index @skipInServerless migrate pre-8.0 action connector ids should be imported into the default space should import a default-space 7.16 rule with a connector made in the default space into a non-default space successfully

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	6486	6520	+34

Async chunks

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

id	before	after	diff
securitySolution	22.2MB	22.2MB	+2.7KB

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
securitySolution	572	571	-1

Total ESLint disabled count

id	before	after	diff
securitySolution	655	654	-1

History

• 💚 Build #263548 succeeded b962e52
• 💔 Build #262545 failed 3cd7d30
• 💚 Build #262212 succeeded 5ed85f5
• 💛 Build #262077 was flaky 1ab0f3c
• 💔 Build #261886 failed 6d84844
• 💔 Build #261868 failed 243d1e7

cc @maximpn