Years and months units aren't supported for 'scale' parameter in decay score function

[igorbunova]

Elasticsearch version: 2.3

JVM version: 1.8.0_66

OS version: linux 3.2.0-106-generic-pae

Description of the problem including expected versus actual behavior:
The documentation says that date units expressions work for 'scale' parameter of the decay function, however not all date time units seem work.

As the user I expect an expression as '10y' or '10Y' work as '10 years'
Also I expect an expression as '2M' work as '2 month'.

Actually years pattern isn't supported and 'M' unit works as minutes.

There is a work-around to write '365d' instead of year and '30d' instead of month, however it will produce slightly different results if the current month has 31, 28 or 29 days or the current year is leap.
If years and months units can't be supported the documentation should have a complete list of supported units (now it isn't obvious)

Steps to reproduce:

1. Create a mapping with the indexed date field
2. Put some documents
3. Perform the fuctional score query with any decay function on your date field and scale with year or month expression

Logs:
Caused by: ElasticsearchParseException[Failed to parse setting [GaussDecayFunctionParser.scale] with value [10y] as a time value: unit is missing or unrecognized]

(see the attachment for stack trace)
log.txt

[dadoonet]

See also #2473 #3841 #7666 #8939 #14802

[clintongormley]

#19649 fixes the misinterpretation of M as minutes. For aggregations, we should try to fix time parsing so that eg 10y works, but date histograms use calendars which is why it makes sense to do it there. The decay functions don't use calendars - just a distance from a point. So 10y isn't going to take leap years etc into account.

I think it is correct to only expose the units that have a real meaning here. If you want to use 3 months in decay functions, then you need to decide how many days that should be (because a day has a determined length, but a month doesn't).

[rjernst]

I think it is correct to only expose the units that have a real meaning here.

By extension of that, we should not support days. Due to daylight savings time, 1 day a year has 23 hours, and 1 day has 25 hours. Hours is the highest granularity that does not change (if you don't count leapseconds!)