Change coerce and range query behavior

[PnPie]

This change includes:

1. coerce option currently only cast string to number, and doesn't cast float/double to byte/short/integer/long (by truncating decimal part).

2. The "numeric range" of a range query doesn't depend on the "range" of field type (ex. integer/long) anymore, that means for example for a BYTE field we can do a range query on [1.5 to 200] (equivalent to [2 to 127]) because it also makes sense.

For the option of truncate/floor/ceil/round number, we can create a new processor to do it ?

Relates to #25861

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[tomcallahan]

@jpountz

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[jpountz]

My preference is that coercedoesn't apply to the query side at all and that we try to do the right thing automatically. For instance [ -2.67 TO 300 ]on a byte field would be equivalent to [ -2 TO 127 ]. This way on the query side you only have to care about the fact that the field is mapped as a number, not its actual type.

I do agree with you that we should try to implement rounding/truncating processors as well at the same time for users who need this kind of functionality.

Also for the record some disagreement was expressed on the issue regarding

[PnPie]

Hello @jpountz
I do agree with you on the range query part because it's does make sense. I updated the PR and also the description on first comment.

[elasticmachine]

Pinging @elastic/es-search-aggs

[javanna]

heya @jpountz I think your last comment was cut around the disagreement. What should we do with this PR?

[jimczi]

We discussed in FixItFriday and decided to close this pr for now. The query part should not be affected by the removal of the coerce option. Moreover we need to make the removal more friendly to users, that means only applying the new rule to new indices created in the version that removed the option. 7.0 is close and we don't have the processors for rounding/truncating so we should postpone the removal to a future version (8.0).