[Security Solution] Extend bulk edit rules API to return skipped rules in response

[jpdjere]

Needed for: #139802
Docs issue: elastic/security-docs#2684

Summary

Introduce a new skipped property in the API response of the /api/detection_engine/rules/_bulk_action endpoint that would contain rules that were intentionally skipped and not updated by the endpoint.

attributes:
  results:
    # new property:
    skipped: [
        { id: "rule id", name: "rule name", skip_reason: "RULE_NOT_MODIFIED" },
    ]
  summary:
    # new property:
    skipped: 1

Add support for skipping rules into the business logic of the RulesClient.bulkEdit() method.

Details

The current behavior of the endpoint is that, if operations on parameters or attributes of the rules result in a no-op, then the update "silently succeeds" and the response reports the rules as being updated. Also, rules saved objects get technically updated under the hood as well, just with the same parameters.

Two current examples of this are:

1. Attempting to add an index_pattern to a rule which is configured to use a data_view, when the option to override data views is not selected.
2. Attempting to add a tag to a rule which already contains that tag in its tag array attribute.

Since the bulk update API allows a user to update properties of a rule that are either attributes as well as params, in order for a rule to consider skipped, all operations attempted on a single rule have to be considered as skipped for the whole rule to be considered skipped. Only in that case should the rule be returned in the skipped property of the API response.

If a rule is considered skipped, then do not update its saved_object or invalidate its api keys.

Note that multiple operations on a single rule on a single API call are only possible when executing the call directly via the API. The usage of this endpoint via the UI does not allow for multiple operations as of yet.

If any one operation is applied to rule successfully, then the rule as a whole should be considered updated and returned in that property of the response.

The skipped rule object does not need to return the whole rule information, but it should contain its id, name and a reason why the rule was skipped. For example:

{ id: "RULE_1_ID", name: "RULE_1_NAME", skip_reason: "RULE_NOT_MODIFIED" }

The updated response of the endpoint should look like this (example):

attributes:
  results:
    created: []
    deleted: []
    updated: []
    skipped: [
        { id: "RULE_1_ID", name: "RULE_1_NAME", skip_reason: "RULE_NOT_MODIFIED" },
        { id: "RULE_2_ID", name: "RULE_2_NAME", skip_reason: "RULE_NOT_MODIFIED" },
    ]
  summary:
    failed: 0
    succeeded: 0
    skipped: 1
    total: 1
rules_count: 1
success: true

Cases for skipping rule updates

1. Attempting to add an index_pattern to a rule which is configured to use a data_view, when the option to override data views is not selected.
2. Attempting to add an index_pattern to a rule which already contains that index pattern in its index array parameter.
3. Attempting to delete an index_pattern from a rule which doesn't contain that index pattern in its index array parameter.
4. Attempting to add a tag to a rule which already contains that tag in its tag array attribute.
5. Attempting to delete a tag from a rule which doesn't contain that tag in its tag array attribute.

[elasticmachine]

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

[elasticmachine]

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

[banderror]

@jpdjere I updated the ticket's description a little bit: added a summary and did a few minor adjustments.

[jpdjere]

Follow up work: as discussed with @spong in #147345 (comment)

we'd like to add additional checks for noop updated in the case of the Bulk Edit type being:

1. set_schedule
2. set_timeline