Allow for additive mappings update without creating a new version index

[rudolf]

In #124946 we will only migrate saved objects to a new version specific index if the mappings changed, otherwise we keep the existing index and only transform outdated documents.

An additional optimization would be to only create a new version specific index if the mappings change is incompatible with the existing index. For instance, adding a new field or a ignore_above to a keyword field can be done in place. Whereas, removing a field or changing a text field type to a numeric one isn't.

The behaviour for when a mappings change is compatible or not isn't always obvious. I can't remember the specifics but I have been surprised in the past that some changes I thought should be compatible weren't. So except for when a field is removed, Kibana should not be trying to determine whether a change is compatible, it should just send the update request to Elasticsearch. If the update succeeds we can proceed without a new index, if not, we need a new version specific index.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[afharo]

Dropping an apparently compatible but not really compatible use case: #147341 adds a compatible change (it adds a field to the mappings). However, a reindex is required so sorting by title.keyword works as expected.

[rudolf]

In #145604 when Kibana starts up and detects the mappings of the index doesn't match what it expects, it will update the mappings, but also run an updateByQuery to "pickup" the new mappings. I didn't previously think of edge cases like this sub-keyword-field, but it is also possible that the document _source contains data in each document that never had an associated field in the mappings. So in general, we can't assume that adding a new field doesn't require updating the lucene index.

Assuming that a new field added to the mappings necessarily requires reading and updating all documents in that index is quite expensive. We could optimise it somewhat by only targeting documents of the type of the saved object that had its mappings update instead of updating all documents. E.g. if a dashboard changes its mappings in a compatible way, we need an updateByQuery on all type: 'dashboard' documents but we can ignore cases.