Geo: linestrings crossing dateline from west to east are not indexed correctly

[imotov]

When a linestring that crosses the dateline from west to east is decomposed, it creates a segment that spans the globe, producing wrong hits. To reproduce: we index a ">" shaped object crossing the dateline twice and then search by intersection with linesting stretching along prime meridian.

DELETE test

PUT test
{
  "mappings": {
    "properties": {
      "shape": {
        "type": "geo_shape"
      }
    }
  }
}

PUT test/_doc/1
{
  "shape": "LINESTRING(160 0,200 10,160 20)"
}

POST test/_search
{
  "query": {
    "geo_shape": {
      "shape": {
        "shape": "LINESTRING(0 -50,0 50)",
        "relation": "intersects"
      }
    }
  }
}

During indexing the decomposition of "LINESTRING(160 0,200 10,160 20)" produces multilinestring ((160.0 0.0, 180.0 5.0),(180.0 5.0, -160.0 10.0, 180.0 15.0),(180.0 15.0, 160.0 20.0)) instead of MULTILINESTRING ((160 0, 180 5), (-180 5, -160 10, -180 15), (180 15, 160 20)) that was produced before. See https://gist.github.com/imotov/cc5d4c42cd9aa1b7dc47d892476f1d46 for illustration of the shapes specified in the repo above, and decomposed shapes in buildS4J and buildGeometry methods. The issue seems to stem from normalizeLon call that was added to buildGeometry and converts -180 to 180.

[elasticmachine]

Pinging @elastic/es-analytics-geo