Create new rule HTTP APIs that use the new terminology

[mikecote]

This is the first step of #90375, which summarizes the new terminology to use in Kibana alerting. This issue covers the rules portion, where we use alert as the current terminology at this time. This new terminology change includes URL, parameters, body, and response in the new APIs. Don't forget docs.

Alerts Plugin Api Paths

Important note: When introducing these new APIs we need to rename all fields in bodies need to be renamed from Camel Case to Snake Case as per our Style Guide. In the code they need to be renamed back to Camel Case.

This change will require changing the Alerts plugin back to it's original name of Alerting, as it becomes confusing with Alerts being renames Rules.

• POST /api/alerts/alert => /api/alerting/rule
• GET /api/alerts/_find => /api/alerting/rules/_find
• GET /api/alerts/alert/{id} => /api/alerting/rule/{id}
• GET /api/alerts/alert/{id}/state => /api/alerting/rule/{id}/state
• GET /api/alerts/alert/{id}/_instance_summary => /api/alerting/rule/{id}/_alert_summary
• GET /api/alerts/list_alert_types => /api/alerting/list_rule_types
• DELETE /api/alerts/alert/{id} => E /api/alerting/rule/{id}
• PUT /api/alerts/alert/{id} => /api/alerting/rule/{id}
• POST /api/alerts/alert/{id}/_enable => /api/alerting/rule/{id}/_enable
• POST /api/alerts/alert/{id}/_disable => /api/alerting/rule/{id}/_disable
• POST /api/alerts/alert/{id}/_mute_all => /api/alerting/rule/{id}/_mute_all
• POST /api/alerts/alert/{alert_id}/alert_instance/{alert_instance_id}/_mute => /api/alerting/rule/{rule_id}/alert/{alert_id}/_mute
• POST /api/alerts/alert/{id}/_unmute_all => /api/alerting/rule/{rule_id}/_unmute_all
• POST /api/alerts/alert/{alertId}/alert_instance/{alert_instance_id}/_unmute => /api/alerting/rule/{rule_id}/alert/{alert_id}/_unmute
• POST /api/alerts/alert/{id}/_update_api_key => /api/alerting/rule/{id}/_update_api_key

For details on the Api migration see the notes under #90375 (comment)

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

re: #93943

I'm curious about the changes of BASE_ALERT_API_PATH -> LEGACY_BASE_ALERT_API_PATH in places like the examples and triggers_actions_ui. We'll need to change these later to the non-legacy base path, but also presumably the subsequent route-specific paths (and params) will need to change as well. Is this all going to happen in the feature branch, or will we end up merging the feature with the legacy paths, and have separate PRs to fix these to use the new paths?

And how will we test the legacy paths? I guess we'll have to duplicate the existing FTs - maybe rename the existing ones "legacy"?

[mikecote]

Is this all going to happen in the feature branch, or will we end up merging the feature with the legacy paths, and have separate PRs to fix these to use the new paths?

The latter, we have a separate issue to move our code to use the new APIs -> #90381. The reason for the split is to break down the work and to have the new APIs as soon as we can so we can ask the teams to convert their code ASAP.

And how will we test the legacy paths? I guess we'll have to duplicate the existing FTs - maybe rename the existing ones "legacy"?

I plan to follow how @gmmorris did it for the connectors in PR: #92451.

[mikecote]

Based on the Alerts Plugin Api Paths in the description, I found a few missing:

• /api/alerts/_aggregate: I decided to go with /api/alerting/rules/_aggregate
• /api/alerts/_health: I decided to go with /api/alerting/_health

Below are some changes I would like to propose:

• /api/alerting/list_rule_types to be /api/alerting/rule_types instead to match the /connector_types API.