[Security Solution] Removes items_per_search and concurrent_searches from upgrade/_review API endpoint logic

[dplumlee]

Summary

Addresses #188061

Removes the threat match fields items_per_search and concurrent_searches from the DiffableRule type we utilize in the upgrade/_review endpoint logic. This omits these fields from the upgrade review workflow as we will never have incoming updates for the fields.

For maintainers

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

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

[nikitaindik]

Thanks @dplumlee! I've taken a look. Left one comment.

[nikitaindik]

Do you think it would be a good idea to add a comment explaining why these two fields are not included in the DiffableRule object?
Otherwise maybe one day someone will notice that they are missing and add them back.

[banderror]

@dplumlee What about the changes in the upgrade/_perform endpoint?

[dplumlee]

@banderror: @jpdjere was going to do that in his upcoming upgrade/_perform PR, but if the work is not too invasive, it could probably be done here too

[banderror]

@dplumlee It will take a lot of time to finalize the upgrade API endpoint. Is there a strong reason for doing it with all the other changes we need to do in it, or we can do it in this PR instead? @jpdjere any opinion?

[jpdjere]

@dplumlee @banderror

I don't think it makes sense to introduce logic in the current shape of the /upgrade/_perform endpoint to force the update of these two fields to the current version. Whatever changes are introduced as part of this PR will definitely be overwritten by the new upgrade logic that I'm working on (although the result will be the same - always update to current under the hood)

The reason I don't think we need to include those changes in this PR is because this is an internal endpoint which we currently use only using a global pick_version of TARGET, so that the fields are overwritten if they are custozimed. But since prebuilt rules are still officially not customizable that's exactly the same behaviour with all other fields that might be customized now via API. So until we actually release the Rule Customization feature, forcing the update of these two fields to CURRENT doesn't make sense specifically. So I'd leave this to the work I'm doing on #191439

[jpdjere]

LGTM ✅

Tested and working as expected:

Before:

After:

I will take care of removing logic related to these fields in /upgrade/_perform

[dplumlee]

@elasticmachine merge upstream

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 9288d1e

Failed CI Steps

• FTR Configs #87

Metrics [docs]

Async chunks

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

id	before	after	diff
securitySolution	20.7MB	20.7MB	-900.0B

History

• 💛 Build #230932 was flaky cd7af0a
• 💛 Build #230203 was flaky 38c8d15
• 💚 Build #227483 succeeded 26a96c1
• 💔 Build #227471 failed 7d79b05
• 💔 Build #227454 failed a7dc057

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

cc @dplumlee