Replaced multi-field type with multi-field syntax.

[martijnvg]

Replaced the multi-field type in favour for the multi fields option that can be set on any core field. The path option isn't changed in this PR.

Options defined in the main core field, are treated as defaults for any multi fields defined under this core field.
When upgrading to ES 1.0 the existing mappings with a multi-field type automatically get replaced to a core field with the new fields option.

Note: Any multi-field type defined in a dynamic template or index template will not be automatically replaced by a core field with multi fields. When dynamic templates or index templates are trigger and multi-field type is defined, then this will be converted in a core field with multi fields in the target mapping being generated.

Relates to #4521

[mattweber]

What happens with something like this? I would like to define a field mapping once then be able to "copy" a fields value into it without requiring additional mapping.

{
     "tweet" : {
         "properties" : {
             "raw": {
                 "type": "string",
                 "index": "not_analyzed"
             },
             "name" : {
                 "type" : "string",
                 "index" : "analyzed",
                 "fields" : {
                     "raw" : {}
                 }
             }
         }
     }
 }

Or if someone is asking for trouble like this? Infinite loop? lol.

{
     "tweet" : {
         "properties" : {
             "name2": {
                 "type": "string",
                 "fields": {
                     "name1": {}
                 }
             },
             "name1" : {
                 "type" : "string",
                 "fields" : {
                     "name2" : {}
                 }
             }
         }
     }
 }

[martijnvg]

In both examples there is no unexpected behaviour, because the path by default is full and as a result of that there are no overlapping fields. The path option can be specified on the same level as where fields is specified.

Consider the following doc:

{
   "name" : "value1",
   "raw" : "value2"
}

With the first mapping this will result in the following field value pairs:

• name : value1
• name.raw: value1
• raw: value2

And the following doc:

{
   "name1" : "value1",
   "name2" : "value2",
}

With the second mapping will result in the following field value pairs:

• name1 : value1
• name1.name2 : value1
• name2 : value2
• name2.name1 : value2

However if the path is specified to be just_name, then the field value pair output is different.

For the first mapping and the first doc:

• name : value1
• raw : value1, value2

For the second mapping and the second doc:

• name1 : value1, value2
• name2 : value1, value2

In order for this behaviour to be working correctly the analyzers of fields that overlap need to be consistent, otherwise unexpected behaviour occurs.

Btw the path option will be replaced with index_path, which allows you to specify a full path for a field. It is a more direct way of specifying the field's name that will be used in the index compared to the current path option.

[martijnvg]

Updated PR:

• Rebased with master.
• Removed the properties inheriting for core fields in fields from main field.
• Made automatic multi_field field type upgrading more lenient. Instead of failing when the default field in a multi_field can't be found, it tries to get the first field from the multi field and use that as main field. When that happens index is set to no for the main field. If the multi_field doesn't have any fields then it becomes a string field, also index is then set to no.

[martijnvg]

Pushed to master: 943b626