Epics: https://github.com/elastic/security-team/issues/1974 (internal), #174168

Summary

In #148184 we implemented a basic version of the upgrade/_perform API endpoint.

We need to enhance this endpoint so it can work with prebuilt rules customized by users and resolve conflicts between user customizations and updates from Elastic in the target version.

Acceptance criteria

• Extend the contract of the API endpoint according to the POC:
• Add the ability to pick the MERGED version for rule upgrades.

If the MERGED version is selected, the diffs are recalculated and the rule fields are updated to the result of the diff calculation. This is only possible if all field diffs return a conflict value of either NO. If any fields returns a value of NON_SOLVABLE or SOLVABLE, reject the request with an error specifying that there are conflicts, and that they must be resolved on a per-field basis.

• Calculate diffs inside this endpoint, when the value of pick_version is MERGED.
• Add the ability to specify rule field versions, to update specific fields to different pick_versions: BASE' | 'CURRENT' | 'TARGET' | 'MERGED' | 'RESOLVED' (See FieldUpgradeRequest in PoC for details)

Handling of special fields

Specific fields need to be handled under the hood based on #186544

Edge cases

• If target version of rule has a rule type change, check that all pick_version, at all levels, match TARGET. Otherwise, create new error and add to ruleErrors array.
• if a rule has a specific targetVersion.type (for example, EQL) and the user includes in its fields object of the request payload any fields which do not match that rule type (in this case, for example, sending in machine_learning_job_id as part of fields), throw an error for that rule.
• Calculation of field diffs: what happens if some fields have a conflict value of NON_SOLVABLE:
  • If the whole rule is being updated to MERGED, and ANY fields return with a NON_SOLVABLE conflict, reject the whole update for that rule: create new error and add to ruleErrors array.
  • EXCEPTION for case above: the whole rule is being updated to MERGED, and one or more of the fields return with a NON_SOLVABLE conflict, BUT those same fields have a specific pick_version for them in the fields object which ARE NOT MERGED. No error should be reported in this case.
  • The whole rule is being updated to any pick_version other than MERGED, but any specific field in the fields object is set to upgrade to MERGED, and the diff for that fields returns a NON_SOLVABLE conflict. In that case, create new error and add to ruleErrors array.