Force selection of calendar or fixed intervals in date histo agg

[polyfractal]

WIP: still needs documentation, and probably some more randomization tests

This adds a calendar_interval and fixed_interval parameter to the date histogram aggregation, as well as deprecating the interval parameter. The two new parameters are mutually exclusive, and cannot be set with interval either. It also deprecates the interval() and dateHistogramInterval() methods of the builder. Finally, it adjusts the composite agg and rollup's to use a similar scheme.

This makes the selection of calendar vs fixed time units explicit to the user, and provides immediate validation of the unit they provide.

This PR should be fully BWC, and throws deprecation warnings where possible.

Some notable points which may need adjusting:

• If the user opts to use the new parameters, we will accept any valid unit even if it "overlaps". For example, 1h can be both a fixed and calendar unit. If the user specifies fixed_interval: 1h, we know it is a fixed hour, as opposed to calendar_interval: 1h which indicates calendar-aware hour.

  If the user continues to use the deprecated interval: 1h, we fall back to the old behavior where we assume units are calendar if possible.

  This felt like the "right" way to do it, rather than forcing the user to understand that a fixed hour had to be specified as 60m, etc.

• DateHisto agg builder was a mess, since it accepted both a fixed long interval and a DateHistogramInterval which could be fixed or cal. And now we have two more parameters. Lastly, this logic needed to duplicated to composite agg too. To keep track of this (and reduce copy/paste between composite agg), there's a new DateIntervalWrapper which records which method is used and enforces which can be set together or not.

  Internally, the wrapper gets rid of the long interval and records everything as a DateHistogramInterval. Once the deprecation period is up this class will be greatly simplified.

• The rollup date histo config just got rid of builders during HLRC refactoring. But now we have interval or one_of(fixed_interval, calendar_interval), which doesn't play nicely with constructing object parsers. So I opted to specialize the DateHistoGroupConfig object into fixed/calendar objects. They just do simple validation and provide a way to tell the configs apart at a later point.

  This let us avoid having weird ctor arguments where two of the three are null (interval, fixed_interval, calendar_interval), and made it easier to deprecate the old way. Happy to entertain a different idea if it's better.

/cc @colings86 @jimczi

[elasticmachine]

Pinging @elastic/es-search-aggs

[polyfractal]

Note: rollup still stores the the interval as interval in rollup docs, although we should move to also storing fixed_interval/calendar_interval. But since this PR is already enormous I'm leaving that for later.

[polyfractal]

Jenkins, retest this please

[polyfractal]

@colings86 @jimczi this still needs documentation, but I wanted to get a sanity check about the approach (two fields, the various caveats/cleanups that had to happen, etc) before proceeding further. Think the approach is ok based on the OP's text?

If yes I'll go ahead and add docs and get tests passing, etc.

[colings86]

I'm happy with the details outlined in the description. This looks like a good route to sorting out these issues to me

[polyfractal]

@elasticmachine run elasticsearch-ci/packaging-sample

[polyfractal]

@elasticmachine run elasticsearch-ci/packaging-sample

[polyfractal]

@elasticmachine run elasticsearch-ci/2

[polyfractal]

@elasticmachine test this please

[polyfractal]

@elasticmachine run elasticsearch-ci/1

[polyfractal]

#41906 has merged, removing backport label and this is done! 🎉