Stop automatically nesting mappings in index creation requests.

[jtibshirani]

The call CreateIndexRequest#mapping(String type, Map<String, ?> source) currently checks if root of the map source is the type name, and if not, makes sure it is nested under the type. It looks like we have this logic because at one point, we tried to maintain the invariant that all mapping values in the request were nested under the type name.

However, since 2341825, this is no longer necessary, and in fact almost none of the other CreateIndexRequest#mapping methods perform this automatic detection + nesting. This PR is a step towards standardizing CreateIndexRequest so that mapping values are not expected to be nested under the type name.

Automatically nesting the mapping values has a few downsides:

• It makes it difficult to introduce fully typeless mapping methods onto this class, as we move towards our goal of removing types. This is because when a typeless mapping definition is provided, it may be automatically converted to one that contains the type. In particular, this logic is making it very hard to deprecate types in the HLRC for 'create index' and 'put index template' requests.

• It is redundant, since the type name is already stored as the key in the mappings map.

• When using the above mapping method then serializing the request to xContent, the mappings will be doubly nested under the type name, as in this example:

  {
    "mappings": {
      "my_type": {
        "my_type": {
          "properties": { ... }
        }
      }
    }
  }
  

  Because of our leniency around mappings, these doubly-nested mappings are still able to be re-parsed. However, this situation is buggy and potentially fragile.

Note that PutIndexTemplateRequest has the same issue, and would have to be changed in an analogous way.

[elasticmachine]

Pinging @elastic/es-core-features

[elasticmachine]

Pinging @elastic/es-search

[jpountz]

Nice.

[markharwood]

Looks like there's some test failures stemming from mixed version clusters. The stack trace suggests it's the 6.7 node attempting some internal merging of mapping definitions from 7.0 and triggers the (removed in 7.0) exception complaining about the lack of root object:

"}],"type":"mapper_parsing_exception","reason":"Failed to parse mapping [doc]: malformed mapping no root object found","caused_by":{"type":"mapper_parsing_exception","reason":"malformed mapping no root object found","stack_trace":"MapperParsingException[malformed mapping no root object found]
	at org.elasticsearch.index.mapper.DocumentMapperParser.extractMapping(DocumentMapperParser.java:179)
	at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:85)
	at org.elasticsearch.index.mapper.MapperService.internalMerge(MapperService.java:395)
	at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:329)
	at org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$IndexCreationTask.execute(MetaDataCreateIndexService.java:452)

[jtibshirani]

Thanks @jpountz for the review, and @markharwood for digging into the build failure. I've decided to pull out the 'Make sure empty mappings are accepted' part of this PR into #37089. I can then backport that PR, which should fix the BWC failures we're now seeing around empty mappings.

[jtibshirani]

@elasticmachine run gradle build tests 1

[jtibshirani]

I'm going to revert this PR because of the issue uncovered in #37208, and I think we need to reconsider the overall approach. In short, the problem is that index templates store the mapping value as a string, with the mapping definition is nested under the type name. When trying to create an index with unnested mappings, we attempt to merge that map with the nested mappings from the index template, which produces an incorrect result.

I now think that instead of standardizing on unnested mappings in indices.create + indices.put_template, for 7.0 we should actually standardize on having all mappings be nested, as @markharwood suggested in #35866. My reasoning is that stored index templates nest the mappings under the type name, so it is more robust and simpler to reason about if we stick to this format across all server requests + code related to index creation.