Allow strings in date range aggregation

[pquentin]

Should fix the following test:

// Test file: /test/free/aggregations/range.yml
// Test name: Range aggregation on date field

import { expectAssignable } from 'tsd'
import * as T from '../types'

expectAssignable<T.SearchRequest>({
  "body": {
    "aggs": {
      "date_range": {
        "range": {
          "field": "date",
          "ranges": [
            {
              "from": "2021-05-01T00:00:00Z",
              "to": "2021-05-05T00:00:00Z"
            }
          ]
        }
      }
    },
    "size": 0
  },
  "index": "date_range_test",
  "typed_keys": true
})

[github-actions]

Following you can find the validation changes against the target branch for the APIs.

API	Status	Request	Response
get	🟢	317/317 → 321/321	314/314 → 318/318
index	🟢	1440/1440 → 1445/1445	1442/1442 → 1447/1447
indices.create	🔴	1373/1397 → 1378/1402	1397/1397 → 1402/1402
indices.get_mapping	🔴	198/198 → 202/202	187/198 → 191/202
search	🔴	2584/2611 → 2586/2612	2611/2611 → 2612/2612

You can validate these APIs yourself by using the make validate target.

[flobernd]

Let me check the consequences of this change for the .NET client please, before you merge it.

FieldValue does not look like the best candidate here at a first glance. Would DateTime work? If I remember correctly this type alles string and timestamp representation. However, not sure why the range was a double before. AFAIK we do have double timestamp types as well, but not yet a combined version like DateTime.

We should probably introduce a new type of DateTime does not fit, to allow statically typed languages to use their native DateTime primitives like we do in all other cases that deal with date/time values.

[flobernd]

Ok, so I checked this in detail and I think the test is simply not valid.

"aggs": {
  "date_range": {
    "range": {

This part makes no sense. date_range does not support a range field. It supports ranges which is correctly typed as ranges?: DateRangeExpression[] and therefore supports both representations (double and string).

The AggregationRange type you changed in this PR is used by GeoDistanceAggregation and the regular RangeAggregation but does not affect DateRangeAggregation.

WDYT @l-trotta @Anaethelion ?

[l-trotta]

@flobernd this is not a date_range aggregation... it's a range aggregation, named "date_range" ^^" still, I also think this test is wrong, I can find no evidence server side that from and to can be strings in the context of range aggregation

[flobernd]

Ah right, the first key is the name of the aggregation. Confusing 😵‍💫

[l-trotta]

had to stare at it for a good 2 minutes