Support coerce JSON -> String

[matthughes]

Continuing conversation started here: https://discuss.elastic.co/t/coerce-object-to-string/56748/3

Description of the problem including expected versus actual behavior:

Would like to be able to treat an object field as String given the following mapping:

          "properties": {
            "severity": {
              "index": "not_analyzed",
              "type": "string"
            },
            "metadata": {
              "type": "string"
              "coerce": true
            }
          }

Indexing the following document:

{
    "severity": "ERROR",
    "metadata": {
        "someKey": "someValue",
        "someKey": {
            "some nested key": "some nested value"
        } 
    }
}

should store the document under metadata as a searchable String.

Right now, it is not possible to coerce anything to a String.

[matthughes]

Right now that mapping above isn't considered valid. ES blows up with:

MapperParsingException[Failed to parse mapping [event]: Mapping definition for [metadata] has unsupported parameters:  [coerce : true]]; nested: MapperParsingException[Mapping definition for [metadata] has unsupported parameters:  [coerce : true]];
    at org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute(MetaDataCreateIndexService.java:332)
    at org.elasticsearch.cluster.ClusterStateUpdateTask.execute(ClusterStateUpdateTask.java:45)
    at org.elasticsearch.cluster.service.InternalClusterService.runTasksForExecutor(InternalClusterService.java:468)
    at org.elasticsearch.cluster.service.InternalClusterService$UpdateTask.run(InternalClusterService.java:772)
    at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.runAndClean(PrioritizedEsThreadPoolExecutor.java:231)
    at org.elasticsearch.common.util.concurrent.PrioritizedEsThreadPoolExecutor$TieBreakingPrioritizedRunnable.run(PrioritizedEsThreadPoolExecutor.java:194)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:744)
Caused by: MapperParsingException[Mapping definition for [metadata] has unsupported parameters:  [coerce : true]]
    at org.elasticsearch.index.mapper.DocumentMapperParser.checkNoRemainingFields(DocumentMapperParser.java:171)
    at org.elasticsearch.index.mapper.DocumentMapperParser.checkNoRemainingFields(DocumentMapperParser.java:165)
    at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:307)
    at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseObjectOrDocumentTypeProperties(ObjectMapper.java:218)
    at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parse(ObjectMapper.java:193)
    at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseProperties(ObjectMapper.java:305)
    at org.elasticsearch.index.mapper.object.ObjectMapper$TypeParser.parseObjectOrDocumentTypeProperties(ObjectMapper.java:218)
    at org.elasticsearch.index.mapper.object.RootObjectMapper$TypeParser.parse(RootObjectMapper.java:139)
    at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:118)
    at org.elasticsearch.index.mapper.DocumentMapperParser.parse(DocumentMapperParser.java:99)
    at org.elasticsearch.index.mapper.MapperService.parse(MapperService.java:498)
    at org.elasticsearch.index.mapper.MapperService.merge(MapperService.java:288)
    at org.elasticsearch.cluster.metadata.MetaDataCreateIndexService$1.execute(MetaDataCreateIndexService.java:329)

[jpountz]

I am not a fan of this feature. Either we could make string fields automatically coerce objects to strings but this would be quite trappy in my opinion: I can certainly imagine users complaining that elasticsearch does not reject documents that do not comply with the mappings. Or we would need a mapping option to enable this behaviour like numerics have to automatically parse strings, but I don't like it either as we already have too many options on mappings. I would rather rely on clients to provide a string that contains escaped json.

[clintongormley]

This is a duplicate of #17918 where we decided against doing it.