defining custom _all field without disabling default one does not fail

[nharraud]

After some mistake (#11851) I found that one can create a custom _all field without disabling the default one, and the default _all field is still used at search time.

Here is the scenario:

DELETE myindex

POST myindex
{
  "mappings": {
    "record": {
        "properties": {
          "_all": {
            "type": "string"
          }
        }
    }
  }
}

==> no error even though default _all field is still enabled. 

PUT myindex/record/1
{
  "title": "my big universe"
}

GET myindex/_search
{
  "query": {
    "match": {
      "_all": "Universe"
    }
  }
}

==> returns the document. Default _all field is still used.

DELETE myindex

POST myindex
{
  "mappings": {
    "record": {
      "_all": { "enabled": false },
        "properties": {
          "_all": {
            "type": "string"
          }
        }
    }
  }
}

PUT myindex/record/1
{
  "title": "my big universe"
}

GET myindex/_search
{
  "query": {
    "match": {
      "_all": "Universe"
    }
  }
}

==> no result. OK

But strangely the search does not work even when I write in the _all field.

PUT myindex/record/1
{
  "_all": "Universe"
}

GET myindex/_search
{
  "query": {
    "match": {
      "_all": "Universe"
    }
  }
}

==> no document even though the _all field has been disabled before. KO

I am using the elasticsearch 1.6 container from docker.io

This is a minor issue as most people won't name their custom fields _all. Throwing an error in the mean time could be useful for people misplacing _all in their mapping. Or maybe forbidding completely the definition of a field named _all.

[clintongormley]

Closing in favour of #10456