Issue title: Bulk API with conflicting fields creates randomly different mapping
 Issue body: **Elasticsearch version** (`bin/elasticsearch --version`): 6.4.0

**Steps to reproduce**:

The following snippet from the console randomly either indexes both documents or correctly throws an error due to the mapping. The `bar` field contains a string in one document and a number in another, and it seems as if the order of indexing gets changed due to the fact which shard indexes first using dynamic mapping and thus decides about the mapping.

An index template or preexisting mapping can properly solve this of course - calling the same endpoint with the same data and getting different results can be confusing for the user though.

```
DELETE foo

PUT foo/doc/_bulk
{ "index" : { "_id" : "2" } }
{ "foo" : "spam", "bar" : 123 }
{ "index" : { "_id" : "3" } }
{ "foo" : "bar", "bar" : "foo" }
```

The first case is this response, where the field gets indexed as a long

```
# DELETE foo
{
  "acknowledged": true
}

# PUT foo/doc/_bulk
#! Deprecation: the default number of shards will change from [5] to [1] in 7.0.0; if you wish to continue using the default of [5] shards, you must manage this on the create index request or with an index template
{
  "took": 526,
  "errors": true,
  "items": [
    {
      "index": {
        "_index": "foo",
        "_type": "doc",
        "_id": "2",
        "_version": 1,
        "result": "created",
        "_shards": {
          "total": 2,
          "successful": 1,
          "failed": 0
        },
        "_seq_no": 0,
        "_primary_term": 1,
        "status": 201
      }
    },
    {
      "index": {
        "_index": "foo",
        "_type": "doc",
        "_id": "3",
        "status": 400,
        "error": {
          "type": "mapper_parsing_exception",
          "reason": "failed to parse [bar]",
          "caused_by": {
            "type": "illegal_argument_exception",
            "reason": """For input string: "foo""""
          }
        }
      }
    }
  ]
}
```

the second case is that both documents are being indexed as string, which happens roghly 50% of the cases

```
# DELETE foo
{
  "acknowledged": true
}

# PUT foo/doc/_bulk
#! Deprecation: the default number of shards will change from [5] to [1] in 7.0.0; if you wish to continue using the default of [5] shards, you must manage this on the create index request or with an index template
{
  "took": 508,
  "errors": false,
  "items": [
    {
      "index": {
        "_index": "foo",
        "_type": "doc",
        "_id": "2",
        "_version": 1,
        "result": "created",
        "_shards": {
          "total": 2,
          "successful": 1,
          "failed": 0
        },
        "_seq_no": 0,
        "_primary_term": 1,
        "status": 201
      }
    },
    {
      "index": {
        "_index": "foo",
        "_type": "doc",
        "_id": "3",
        "_version": 1,
        "result": "created",
        "_shards": {
          "total": 2,
          "successful": 1,
          "failed": 0
        },
        "_seq_no": 0,
        "_primary_term": 1,
        "status": 201
      }
    }
  ]
}
```

You can verify the different mapping by checking the `bar` field in both cases

```
GET foo/doc/_mapping?filter_path=**.bar
```
 Comments: 
 Comment 0: This is expected? Each shard processes its share of the bulk request independently and the first one that introduces a mapping for `bar` wins.
{'source': 'GithubIssues', 'repo_name_with_owner': 'elastic/elasticsearch', 'issue_id': 361433095, 'repo_stars': 55977.0}