Lessen leniency of the query dsl.

[jpountz]

This change does the following:

• Queries that are currently unsupported such as prefix queries on numeric
  fields or term queries on geo fields now throw an error rather than returning
  a query that does not match anything.
• Fuzzy queries on numeric, date and ip fields are now unsupported: they used
  to create range queries, we now expect users to use range queries directly.
  Fuzzy, regexp and prefix queries are now only supported on text/keyword
  fields (including _all).
• The _uid and _id fields do not support prefix or range queries anymore as
  it would prevent us to store them more efficiently in the future, eg. by
  using a binary encoding.

Note that it is still possible to ignore these errors by using the lenient
option of the match or query_string queries.

[jpountz]

If this change is approved I'll work on adding deprecation warnings on 2.x.

[rjernst]

Having an empty ctor body will also use the default super ctor, so I think this super() is not necessary?

[rjernst]

LGTM, I left a couple minor comments.

[jpountz]

@clintongormley just informed me that removing the support for fuzzy queries on numeric fields in query strings had been previously rejected in #4076. @kimchy Do you still have concerns about stopping to support fuzzy queries on numeric/date/ip fields?

[danielmitterdorfer]

@jpountz we have an open issue to remove fuzzy query entirely in 6.0 (see #15760). So we should close this one too if we don't remove it...

[jpountz]

@danielmitterdorfer If my understanding is correct, the concern is more about removing support for the fuzzy operator ~ in query strings than removing the fuzzy query.

[danielmitterdorfer]

@jpountz Ok, I was just double-checking.

[kimchy]

@jpountz I find the ability to use the fuzzy operator in a query string to be simpler to use in things like Kibana query string and so on. Is there a reason you want to remove it? I always viewed it as a "range query" operator, just apply to other types. To me, it does make sense to have age:10~2 instead of doing the long form range query sample. But if I am in a minority, no problem with removing.

[jpountz]

First I wanted to remove it for ip addresses since it does not make much sense now that we support ipv6 (the deltas would need to be huge for it to be useful). So then I questioned whether this is useful at all on numeric/date fields and I could not remember of any bug/discussion about this feature, even though it certainly has bugs (for instance, it did not check for overflows). So I am leaning towards removing it, especially given that the range is easy to type too, and this gives us a single way to search ranges of values, which I think prevents confusion.

[kimchy]

Adrien, lead the way :)