Merge V2 index/component template mappings in specific manner

[dakrone]

This commit changes the way that V2 index, component, and request mappings are merged. Specifically:

• Fields are merged in a "replacement" manner, meaning that the entire definition is replaced rather
  than merging the interior configuration
• Mapping metadata (all fields outside of properties) are merged recursively.

The merging for V1 templates does not change.

Relates to #53101

[elasticmachine]

Pinging @elastic/es-core-features (:Core/Features/Indices APIs)

[andreidan]

LGTM thanks Lee

Left only a minor suggestion

[andreidan]

innerTemplateMapping is only used to initialize innerTemplateNonProperties

Would it make sense for these statements to be executed in reversed order to avoid over allocating innerTemplateNonProperties just to immediately remove "properties" ?

ie.

Map<String, Object> maybeProperties = (Map<String, Object>) innerTemplateMapping.remove("properties");
Map<String, Object> innerTemplateNonProperties = new HashMap<>(innerTemplateMapping);

[andreidan]

Ah, ignore this actually, as we'd be modifying a map we didn't create. It's fine as it is

[dakrone]

(Some builds were aborted due to Jenkins restart)

@elasticmachine run elasticsearch-ci/bwc
@elasticmachine run elasticsearch-ci/oss-distro-docs
@elasticmachine run elasticsearch-ci/packaging-sample-matrix-windows
@elasticmachine run elasticsearch-ci/packaging-sample-unix-archives
@elasticmachine run elasticsearch-ci/packaging-sample-unix-docker
@elasticmachine run elasticsearch-ci/packaging-sample-unix-packages

[elasticmachine]

Pinging @elastic/es-search (:Search/Mapping)

[jtibshirani]

This caught my eye as I was looking at open PRs. The current behavior is a bit unexpected to me -- we only replace the top-level keys, as opposed to the field definitions. For example, my understanding is that merging these two mappings

{
  "properties": {
    "object": {
      "foo": { "type": "keyword" }
    }
}

{
  "properties": {
    "object": {
      "bar": { "type": "keyword" }
    }
}

will currently result in

{
  "properties": {
    "object": {
      "bar": { "type": "keyword" }
    }
}

Is this the intended behavior? It seems like we would want to be able to introduce new fields, even if they shared a parent object with an existing field.

I'm also wondering if we want to merge all the non-properties blocks recursively. For example in #29200 we discussed that we'd like dynamic templates to replace existing ones with the same name.

[jtibshirani]

@jpountz had a good observation about dots in field names. Given a low-priority template with an object field object, and a high-priority template with the key object.field, the object field does not get replaced. Instead you end up with two top-level keys, object and object.field.

To me this produces pretty subtle behavior -- sometimes top-level fields are overwritten, sometimes they are not.