Mapping: First index of nested value as an array fails when dynamic is strict

[clintongormley]

This works on 1.3.1, fails in master:

DELETE /myapp
PUT /myapp
{
   "mappings" : {
      "multiuser" : {
         "properties" : {
            "timestamp" : {
               "type" : "date"
            },
            "entry" : {
               "properties" : {
                  "last" : {
                     "type" : "string"
                  },
                  "first" : {
                     "type" : "string"
                  }
               },
               "dynamic" : "strict",
               "type" : "nested"
            }
         },
         "_timestamp" : {
            "path" : "timestamp",
            "enabled" : 1
         },
         "numeric_detection" : 1,
         "dynamic" : "strict"
      }
   },
   "settings" : {}
}

POST /myapp/multiuser?op_type=create
{
   "timestamp" : 1408198082386,
   "entry" : [
      {
         "first" : "john",
         "last" : "smith"
      }
   ]
}

This throws: StrictDynamicMappingException[mapping set to strict, dynamic introduction of [entry] within [multiuser] is not allowed]

at org.elasticsearch.index.mapper.object.ObjectMapper.serializeArray(ObjectMapper.java:604)
at org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:489)
at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:533)
at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:482)
at org.elasticsearch.index.shard.service.InternalIndexShard.prepareCreate(InternalIndexShard.java:384)
at org.elasticsearch.action.index.TransportIndexAction.shardOperationOnPrimary(TransportIndexAction.java:193)
at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:532)
at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:431)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

[clintongormley]

@colings86 i think this may be related to the change in #6939

[jpountz]

I'm not sure this change needs version labels since the bug has not been released?