[CI] RangeQueryBuilderTests fails reproducibly

[tvernum]

It failed on CI for 7.0, but reproduces on master
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+7.0+intake/654/console

./gradlew :server:unitTest -Dtests.seed=C6257F2747659030 -Dtests.class=org.elasticsearch.index.query.RangeQueryBuilderTests -Dtests.method="testToQuery" -Dtests.security.manager=true -Dtests.locale=sk -Dtests.timezone=Asia/Kolkata -Dcompiler.java=12 -Druntime.java=12

ERROR   1.74s | RangeQueryBuilderTests.testToQuery <<< FAILURES!
   > Throwable #1: java.lang.IllegalArgumentException: min value (101) is greater than max value (100)

[elasticmachine]

Pinging @elastic/es-search

[cbuescher]

This looks like a rarely triggered case that happens with range queries when from/to being just 1 unit apart and includeLower/includeHigher are both false. Looking into this.

[cbuescher]

Currently (6.7+), when we issue a search on e.g. an integer_range field like this:

GET range_index/_search
{
  "query" : {
    "range" : {
      "expected_attendees": { 
        "gt" : 10,
        "lt" : 11,
        "relation" : "intersects" 
      }
    }
  }
}

We get the following error:

"failed_shards": [
      {
        "shard": 0,
        "index": "range_index",
        "node": "1xw_KWE3QvSmXBkkWgDm-w",
        "reason": {
          "type": "query_shard_exception",
          "reason": "failed to create query: {\n  \"range\" : {\n    \"expected_attendees\" : {\n      \"from\" : 10,\n      \"to\" : 11,\n      \"include_lower\" : false,\n      \"include_upper\" : false,\n      \"relation\" : \"intersects\",\n      \"boost\" : 1.0\n    }\n  }\n}",
          "index_uuid": "UAljwH81Rzudxhl817scVg",
          "index": "range_index",
          "caused_by": {
            "type": "illegal_argument_exception",
            "reason": "min value (11) is greater than max value (10)"
          }
        }
      }
    ]

This is technically right because with gt/lt this means the range calculated internally is empty. I wonder if we should fix the test so this cannot happen and keep the error or fix throwing an error and return a MatchNoDocs query here instead. But that would probably mean also not throwing errors on queries where from cleary > to:

{
  "query" : {
    "range" : {
      "expected_attendees": { 
        "gt" : 15,
        "lt" : 10,
        "relation" : "intersects" 
      }
    }
}

Or we could only prevent the error if the lower value <= higher value but the "includeUpper/Lower" setting causes the bounds to reverse...