Remove type level default analyzers

[rjernst]

Notes for reviewers:

• I moved the Analyzer used by indexing operations in Engine to a separate parameter. The fact that these operations need the DocumentMapper is sneaky, and only used for updating mappings on master. Hopefully future cleanups with how mappings are applied will allow removal of the DocumentMapper parameter altogether. (e.g. Mappings: make mappings immutable #9365).
• The addition of these settings to static bwc index creation is partial here (only for 1.4.2). There is more work to do on those tests, so I chose to only update one index in order to have some test coverage, but leave full regeneration of all the indexes for a separate issue.

closes #8874

[jpountz]

The change looks good. Something that I'm missing is what the expected behaviour is when a user upgrades from 1.x to 2.x. I see the parsing logic has been removed from DocumentMapperParser so I believe that starting a 1.x index with per-type default analyzers would fail on 2.x?

[clintongormley]

@jpountz good catch. There are two conflicting needs here:

• to inform the user that the _analyzer field no longer works
• to allow the user to continue using their data without reindexing, even though the _analyzer field no longer has any effect

I think we should throw an exception by default, so that the user knows that there is a problem (rather than just silently changing behaviour), but we need to provide some way for the user to say "go ahead and use this index anyway".

Possibilities:

• apply a setting to the closed index to say "ignore the _analyzer field", then allow opening the index
• perhaps just upgrade the mapping to remove the _analyzer field if the user manually opens the index (or add a "force" flag to the open API?)
• add functionality to the upgrade API to make the required mapping changes

any preferences or better ideas?

[rjernst]

I see the parsing logic has been removed from DocumentMapperParser so I believe that starting a 1.x index with per-type default analyzers would fail on 2.x?

That's what I thought at first, and had extra logic in the parser to log and skip when it saw these old settings. However, I found that this worked even without my extra logic (with the restore bwc tests). The validation function, which checks if there are any extra settings, only throws exception on index creation on or after 2.0. If the index was created before 2.0, it only logs a warning.

@clintongormley This PR is for removing per type analyzer defaults... _analyzer was a different issue, but you are right we should have an issue to address bwc (and I think we can test it similar to what I did here with the static bwc indexes).

[clintongormley]

@rjernst sorry, mixed up the issues, although the same problems exist here. Let's deal with this problem separately in #9443

[jpountz]

The validation function, which checks if there are any extra settings, only throws exception on index creation on or after 2.0. If the index was created before 2.0, it only logs a warning.

I had missed it was only enabled for new indices! Thanks for the explanation.

[jpountz]

LGTM

[clintongormley]

Docs need updating: http://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-root-object-type.html#_index_search_analyzers

[rjernst]

@clintongormley I removed the documentation for it in master and added a deprecation warning in 1.x.