Geo: handling of out of bounds coordinates in geo_point

[imotov]

Currently, out of bounds points (with longitude outside of -180 - +180 and latitude outside of -90 0 +90) are handled in a slightly different manner for different types of shapes in geo_shape type, which we are addressing in #43916. So, should we bring geo_point in line with geo_shape as well? Today, the geo_point's treatment of the ignore_malformed flag differs from geo_shape and all other types it essentially combines 2 flags together: ignore_malformed and coerse. Typically ignore_malformed controls if a record will be indexed if it contains a field with malformed value, and if it is set to true and the field contains a malformed value the field is not indexed. coerce on another hand, transforms the value into compatible type and the field is indexed. In case of the geo_point type, ignore_malformed behaves as coerse if the value is formatted correctly but the coordinates are out of bounds and it behaves as ignore_malformed if the value is formatted incorrectly.

I would like to propose to always accept out of bounds values and index them the same way as we index these values in geo_shapes and bring ignore_malformed in line with other types.

To summarize today's behaviour is:

• "point": "1000,1000"
  • record is rejected if ignore_malformed is false
  • record is indexed, field is normalized and indexed if ignore_malformed is true
• "point": "foo bar"
  • record is rejected if ignore_malformed is false
  • record is indexed, field is ignored if ignore_malformed is true

Proposed behaviour:

• "point": "1000,1000"
  • record is indexed, field is normalized and indexed regardless of ignore_malformed
• "point": "foo bar"
  • record is rejected if ignore_malformed is false
  • record is indexed, field is ignored if ignore_malformed is true

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Geo)

[wchaparro]

Removing team-discuss label. We discussed and would like to address this change as part of a larger Geo refactoring initiative that @iverase will design a plan for. He'll create a meta issue to address this change, and will close out this issue when in place.