[Security Solution] RulesManagementClient refactoring. Part 1

[jpdjere]

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

‼️ Part of critical path ‼️

• Needed for: [Security Solution] Write the rule_source field together with immutable #180141

Summary

As part of the preparatory changes for Prebuilt Rules Customization Milestone 3, we want to refactor rule management CRUD utilities into a new abstraction with tentative name RuleManagementClient.

Currently, the CRUD utilities that our endpoints use suffer from the problem of tightly coupled logic, which leads them to having unnecessary complex interfaces and logic in order to handle all the different use cases for which they are used.

We aim for the new abstraction to deliver two main improvements:

1. Separation of concerns that reduces tightly-coupled logic: rule management utilities should be use-case specific instead of generic. For example, the current createRules utility is used for creating custom rules, importing rules and upgrading rules. Instead, create specific utilities for each use case.
2. Provide an abstraction where we can centralize migration on write and normalization on read logic

Background

kibana/x-pack/plugins/security_solution/docs/rfcs/detection_response/prebuilt_rules_customization.md

Lines 402 to 425 in 07706fd

	### Problem with tightly coupled logic in our endpoints
	All endpoints belonging to Detection Rules Management that create and update -including upgrade of prebuilt rules to new version- use three CRUD methods under the hood:
	- [`createRules`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/rule_management/logic/crud/create_rules.ts)
	- [`patchRules`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/rule_management/logic/crud/patch_rules.ts)
	- [`updateRules`](https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/rule_management/logic/crud/update_rules.ts)
	This "overuse" of these 3 methods for a variety of user actions makes their logic tightly coupled and creates a considerable amount of complexity to CRUD functions that should remain logically simple.
	For example: the `createRules` method is used in 3 use cases:
	1. when creating custom rules with our Rule Creation endpoints
	2. when importing rules, when the imported `rule_id` does not already exist in Kibana
	3. when upgrading rules, if a rule undergoes a `type` change, the existing rule is deleted a new one is created.
	The same happens with `patchRules`. It is used:
	1. when patching rules via our Rule Patch endpoints
	3. when upgrading rules, if a rule maintains its `type`.
	This causes these 3 CRUD functions to have an unnecessary complex interfaces and logic in order to handle all these different use cases.
	As part of the epic, we should move away from this practice and create new CRUD methods that handle the different cases mentioned above specifically. This will help simplify our existing methods, keep logic in all of our CRUD methods simple and logically uncoupled from one another.

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[elasticmachine]

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

[xcrzx]

I've listed all remaining work in this follow-up ticket: #184364.