[WIP] Scaling Saved Objects fields count

[rudolf]

As we're adding more plugins and more saved object types we're hitting the default field count limit of 1000 on the .kibana index.

Here's a table outlining the saved object type and field count for select versions since 6:

Kibana version	Saved object types	Field count*
6.0.0	13	66
6.5.4	19	102
6.8.14	26	161
7.0.1	24	161
7.1.1	24	161
7.2.1	30	261
7.3.2	33	273
7.4.2	32	268
7.5.2	36	325
7.6.2	42	395
7.7.1	50	732
7.8.1	50	743
7.9.3	62	732
7.10.2	60	673
7.11.1	68	714

• (Fields in the .kibana index "out of the box", Kibana might add more fields as users create more saved objects)

Short term:

• Reduce field count on telemetry objects Don't index so many saved object fields #43673
• Reduce core's dynamic fields Use dynamic: false for config saved object mappings #70436
• Cleanup unused saved object types Saved Object Migrations should clean up unused mappings #67086
• Print .kibana field count stats for every CI run
• Increase field count to 1500

Medium term:

• Core should expose a way for plugins to specify a validation function for their objects.
• Teams should add validation to saved object types and not rely on ES fields for this. Remove all fields that aren't searched, aggregated or sorted over.

Long term:

• Index per solution, plugin, or even per type? Would require the ability to migrate a Saved Object type from one index to another Migrate saved-object types between indices #90817.
• Perhaps lazily create indices so that Kibana doesn't create ~70 indices on startup, but only creates indices as users use plugins that start writing saved objects. E.g. Only once I create a dashboard the .kibana_dashboard index gets created.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mikecote]

Long term:

Index per solution, plugin, or even per type? Would require the ability to migrate a Saved Object type from one index to another.

The @elastic/kibana-alerting-services team has been struggling at making alert parameters searchable across different types of alerts (see #50213). Since we need to support filtering, sorting, and free-text searching across types, the index per type would be an interesting path that we could research together to see if it would solve our problem.