[Security Solution] Implement `concurrent_searches` and `items_per_search` fields diff algorithms

[jpdjere]

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

Summary

Implement algorithms for diffing and merging changes in concurrent_searches and items_per_search fields

These two fields require a specialized algorithm because of the following reasons:

• These fields can be modified via the API, although we've made a decision not to enable modifications via the UI.
• This can cause conflicts when rule updates that include changes for these fields are released.
• We want the response of the /upgrade/_review endpoint to include the diff calculation for these fields, but they shouldn't show up in the UI, since that would allow the user to customize it via the UI, during the upgrade workflow.
• Instead, we will make this algorithm specific so that in cases of an ABC conflict scenario, the value for the conflict prop for these fields will be NO. This way we can ensure that these two fields are not displayed in the upgrade workflow UI. The value for the merged_version should be the current_version.

• The field diff for an ABC scenario for these two fields should be:

  {
  base_version: baseVersion,
  current_version: currentVersion,
  target_version: targetVersion,
  merged_version: mergedVersion, // which equals the `current_version`
  
  diff_outcome: ThreeWayDiffOutcome.CustomizedValueCanUpdate,
  merge_outcome: ThreeWayMergeOutcome.Merged,
  has_update: true,
  conflict: ThreeWayDiffConflictResolutionResult.NO
  };

Context from the Rule Customization RFC:

• Concrete field diff algorithms by type

To do

• [x] Remove fields from upgrade review workflow

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

[banderror]

@jpdjere Thanks for creating this ticket. One small reminder, please: every ticket in the backlog should have custom fields filled in, because that's what powers all our tabs in the GH project. I moved it to Inbox for now, but feel free to fill them in and move back to Backlog

[yctercero]

@jpdjere is this work still required if we feel these fields should be deprecated? I guess even if they are we'll need to support past versions having it.

[dplumlee]

I think this work would be needed no matter what, but what might be a better way forward is to delete the fields from the DiffableRule type and instead just always use the current version as we don't seem to push updates to these fields anyways since they're performance based. This will forgo any elastic specific updates but will just automatically keep the user customized fields if they have changed them.

Right now, I'm not sure we'd need a diff algorithm for it as we will never return the fields in the eyes of the users anyways

[dplumlee]

Closed by #190440