[Security Solution] Allow users to edit max_signals field for custom rules

[dplumlee]

Resolves: #173593
Fixes: #164234

Summary

Adds a number component in the create and edit rule forms so that users are able to customize the max_signals value for custom rules from the UI. Also adds validations to the rule API's for invalid values being passed in.

This PR also exposes the xpack.alerting.rules.run.alerts.max config setting from the alerting framework to the frontend and backend so that we can validate against it as it supersedes our own max_signals value.

Flaky test run (internal)

Screenshots

Form component

Details Page

Error state

Warning state

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
• Flaky Test Runner was used on any tests changed
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)

For maintainers

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

[dplumlee]

How do we feel about selecting the name for max_signals to be "Max signals"? Obviously that's the field name but seeing as this is the first time (other than maybe this) we're exposing this value to users in the UI and not just the API, do we want to call it as such? The field was created back when we were still using the signals language instead of alerts. cc @joepeeples @approksiu

[joepeeples]

How do we feel about selecting the name for max_signals to be "Max signals"? Obviously that's the field name but seeing as this is the first time (other than maybe this) we're exposing this value to users in the UI and not just the API, do we want to call it as such? The field was created back when we were still using the signals language instead of alerts. cc @joepeeples @approksiu

Haha, jinx, we both asked the same thing just now. 😜 I think "Max alerts" is a more meaningful label to users — I assume we can't also rename the field itself (due to breaking changes, etc)? It might be a little odd to have different names in the UI and in the data, but I don't know if users are likely to notice, if max_signals isn't directly exposed to them.

[dplumlee]

@joepeeples yeah, we can't easily rename the field without a lot of problems but in the one prior example we have of referring to the value in the UI, we use "max alerts" so I reckon that's probably a good enough solution. It won't break anything for API users anyways so I don't think we would run into too much confusion adding it to the rule forms. I'll go ahead and do that then unless @approksiu had another idea in mind.

[dplumlee]

/ci

[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)

[pmuellr]

Thanks for the changes!

[jpdjere]

@dplumlee I'm trying to get the Serverless URL and credentials to allow for testing, but for whatever reason that step failed. I'll rerun CI.

[jpdjere]

/ci

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3cbb10f
• Cloud Deployment
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-179680-3cbb10ffb2f2
• Security Deployment

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5477	5479	+2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
alerting	829	830	+1

Async chunks

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

id	before	after	diff
securitySolution	13.7MB	13.7MB	+3.4KB

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id	before	after	diff
module count	-	5407	+5407
total size	-	8.8MB	+8.8MB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
alerting	23.7KB	23.9KB	+201.0B
securitySolution	83.3KB	83.4KB	+43.0B
total			+244.0B

Unknown metric groups

API count

id	before	after	diff
alerting	861	862	+1

History

• 💔 Build #207853 failed c850892
• 💚 Build #207751 succeeded 18a724f
• 💚 Build #207688 succeeded d0e0432
• 💔 Build #207660 failed 8d02476

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

cc @dplumlee