[Index patterns] Default index pattern REST API

[Dosant]

Summary

close #97337

Adds new routes for index patterns REST API.

I just mimicked the API of the existing index pattern service to keep things simpler.

Get the id of the default index pattern

GET /api/index_patterns/default

returns index pattern id or null

{
  "index_pattern_id": "..."
}

Set default index pattern by id if no currently set

POST /api/index_patterns/default 
{
  "index_pattern_id": "<id>" 
}

Force default index pattern id using force modifier

POST /api/index_patterns/default 
{
  "index_pattern_id": "<id>",
  "force": true 
}

returns

{
 "acknowledged": true
}

Please note: there is no validation that supplied index pattern id exists. This is done to give more flexibility when using the API.

Thoughts

@mattkime, Index pattern REST API uses IndexPatternsService which is a common service reused between client and server. Should we consider refactoring this in the future, so that the client-side service starts using REST API internally instead of saved object client directly?

Checklist

• Documentation was added for features that require explanation or tutorials . blocked by [Docs] Index patterns REST API docs #100549
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

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

Release Notes

Expose default index pattern management in index patterns REST API

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[mattkime]

Should we consider refactoring this in the future, so that the client-side service starts using REST API internally instead of saved object client directly?

I'm not certain if there are clear advantages of doing this, perhaps you're aware of some. My first thoughts are we'd want to make sure we preserve type safety.

[mattkime]

I think this still needs docs similar to https://github.com/elastic/kibana/pull/100549/files

[Dosant]

I think this still needs docs similar to https://github.com/elastic/kibana/pull/100549/files

👍 When I opened this one the docs pr hasn't been merged yet. Now since it has been merged I updated docs!

I'm not certain if there are clear advantages of doing this, perhaps you're aware of some. My first thoughts are we'd want to make sure we preserve type safety.

One practical benefit is that we would potentially reduce places where we have sequential networks calls from browser

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: c9f1a77
• Storybooks Preview
• Documentation Changes

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
data	817.5KB	817.7KB	+178.0B

Unknown metric groups

API count

id	before	after	diff
data	3764	3768	+4

References to deprecated APIs

id	before	after	diff
canvas	29	25	-4
crossClusterReplication	8	6	-2
fleet	22	20	-2
globalSearch	4	2	-2
indexManagement	12	7	-5
infra	261	149	-112
lens	67	45	-22
licensing	18	15	-3
lists	239	236	-3
maps	286	208	-78
ml	121	115	-6
monitoring	109	56	-53
securitySolution	386	342	-44
stackAlerts	101	95	-6
total			-342

History

• 💚 Build #127429 succeeded 5474508
• 💔 Build #127423 failed 3a89bd2

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

[mattkime]

looks good!