feat(slo): introduce SLO templates API

[kdelemme]

Resolves #246779
Pre-requisite for #245854

Summary

This PR introduces two new internal routes and a new repository for the new SLOTemplate saved objects.
The routes can be used to fetch a specific SLOTemplate from its id, or search through them (search on name, filter on tags).

Integration tests have been added to make sure we are able to construct a valid SLO Template based on partially stored object.

Note

Expectation from reviewer is a code review. Manual testing can be done, but you will have to follow the instructions from #245903. You can always call the API without having any slo templates.

[Copilot]

Pull request overview

This PR introduces two new internal API endpoints for SLO templates: GET /api/observability/slo_templates/{templateId} to retrieve a single template and GET /api/observability/slo_templates to search/find templates with filtering and pagination support. The implementation includes a new repository layer for accessing SLO template saved objects, comprehensive validation and filtering logic to handle partial or invalid templates, and extensive test coverage with edge cases.

Key changes:

• New SLO template repository with validation and filtering of stored templates
• Two REST API endpoints with pagination, search, and tag filtering capabilities
• Comprehensive test suites covering valid, partial, invalid, and edge-case scenarios

Reviewed changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
slo_api.ts	Adds test helper methods getTemplate and findTemplates; relocates existing helper methods
index.ts	Registers new test files for template endpoints
get_slo_template.ts	Comprehensive tests for GET single template endpoint covering valid, partial, invalid, and error cases
find_slo_templates.ts	Extensive tests for find/search endpoint including pagination, search, tag filtering, and validation errors
slo_template_repository.ts	Implements repository with field-level validation and filtering logic for stored templates
slo_template.ts	Updates saved object type definition with safer type checking for template name
types.ts	Adds SLOTemplateRepository to scoped clients interface
slo_templates.ts	Implements two route handlers with platinum license check and parameter validation
route.ts	Registers new template routes in route repository
create_slo_server_route.ts	Adds error handling for SLOTemplateNotFound error type
plugin.ts	Instantiates template repository and includes it in scoped clients
errors.ts	Defines new SLOTemplateNotFound error class
slo_template.ts (domain)	Updates type definitions to use new schema types
index.ts (domain)	Updates export to use renamed template type file
slo_template.ts (schema)	Defines template schema with all fields optional and stored template as unknown record
slo.ts (schema)	Removes old template schema definition
index.ts (schema)	Exports new template schema
slo_templates.ts (rest_specs)	Defines parameter schemas and response types for both endpoints
index.ts (rest_specs)	Exports template route specifications

[kdelemme]

💬 Decided to not create application services for these route handlers since the orchestration logic is very simple.

[kdelemme]

🤖-generated, 👨🏻-reviewed

[kdelemme]

🤖-generated, 👨🏻-reviewed

[elasticmachine]

Pinging @elastic/actionable-obs-team (Team:actionable-obs)

[baileycash-elastic]

Looks good, small question:

We have validation here for pagination, will the same checks be applied to the existing SLO find service?

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 253027c

Failed CI Steps

• FTR Configs #132
• Scout: [ platform / discover_enhanced ] plugin

Test Failures

• [job] [logs] Scout: [ platform / discover_enhanced ] plugin / dont show up if outside of range
• [job] [logs] Scout: [ platform / discover_enhanced ] plugin / serverless-security - Discover app - value suggestions: useTimeRange enabled - dont show up if outside of range

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
observability	1709	1711	+2
slo	1336	1338	+2
synthetics	1375	1377	+2
total			+6

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/slo-schema	232	242	+10

Async chunks

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

id	before	after	diff
observability	1.7MB	1.7MB	+548.0B
slo	995.4KB	995.9KB	+548.0B
synthetics	1.0MB	1.0MB	+545.0B
total			+1.6KB

Unknown metric groups

API count

id	before	after	diff
@kbn/slo-schema	233	243	+10

cc @kdelemme

[kdelemme]

We have validation here for pagination, will the same checks be applied to the existing SLO find service?

We should already have some validation for the find slo service, if some are missing we can always add them for sure. Would be nice to leverage arrayToStrings.pipe(t.array(t.string)) for the various tags query parameter we use elsewhere.

[dmlemeshko]

x-pack/solutions/observability/test/api_integration_deployment_agnostic/services/slo_api.ts changes LGTM