anchor.diff:  }
   POST /test/_bulk?refresh
   {"index": {}}
  -{"s": 1, "m": 3.1415, "i": 1, "d": "2020-01-01T00:12:12Z"}
  -{"index": {}}
  -{"s": 2, "m": 1.0, "i": 6, "d": "2020-01-02T00:12:12Z"}
  -{"index": {}}
  -{"s": 3, "m": 2.71828, "i": -12, "d": "2019-12-31T00:12:12Z"}
  +{"s": 1, "m": 3.1415, "i": 1, "d": "2020-01-01T00:12:12Z", "t": "cat"}
  +{"index": {}}
  +{"s": 2, "m": 1.0, "i": 6, "d": "2020-01-02T00:12:12Z", "t": "dog"}
  +{"index": {}}
  +{"s": 3, "m": 2.71828, "i": -12, "d": "2019-12-31T00:12:12Z", "t": "chicken"}
   POST /test/_search?filter_path=aggregations
   {
     "aggs": {
  
positive.code:         "metrics": {
            "m": 2.718280076980591,
            "i": -12,
            "d": "2019-12-31T00:12:12.000Z"
          }
        } ]
      }
  
negative.code: The `sort` field in the metric request functions exactly the same as the `sort` field in the
  <<sort-search-results, search>> request except:
  
  * It can't be used on <<binary,binary>>, <<flattened,flattened>>, <<ip,ip>>,
    <<keyword,keyword>>, or <<text,text>> fields.
  * It only supports a single sort value so which document wins ties is not specified.
  
  The metrics that the aggregation returns is the first hit that would be returned by the search
  