Geo: extract dateline handling logic from ShapeBuilders

[imotov]

Extracts dateline decomposition logic from ShapeBuilder into a separate
utility class that is used on the indexing side. The search side
will be handled as part of another PR at this time we will remove
the decomposition logic from ShapeBuilders as well. This PR also doesn't
change any existing logic including bugs.

Relates to #40908

[elasticmachine]

Pinging @elastic/es-analytics-geo

[nknize]

So it looks like this always assumes spherical geometries and splits across the 180 degree longitude boundary. To support XY cartesian geometries I think we should either:

1. tease out the base geometry building logic into a base class, and move the GIS decomposition logic into a derived class (e.g., SphericalGeometryIndexer) so we can extend to a CartesianGeometryIndexer in the geo xpack module.
2. update this class constructor to accept an isGeo parameter and only call decompose if set to true. This way we can build cartesian Geometry in core and implement the XY geometry building logic in the toLucenePolygon method inside GeometryFieldMapper of the xpack geo module

I like 2 because I think it makes the building logic more friendly for the REST API?

[imotov]

@elasticmachine run elasticsearch-ci/default-distro

@nknize I was thinking about going the first route actually. I would like to make the Indexing logic easily swap-able, in order to fix the issues that I have stumbled upon this refactoring (such as #43916, #43837, #43826, #43775) in a backward-compatible manner.

[talevy]

LGTM I can't wait for the follow-up PR that removes all the other stuff!

[nknize]

@imotov Just a quick follow up from our conversation: are you still planning on moving GeometryIndexer out of o.e.common.geo since it's only used in GeoShapeFieldMapper? I assumed we would do it in this PR. I think it's fine to move it as package private to o.e.index.mapper since it's never used outside of the Mapping?

[imotov]

think it's fine to move it as package private to o.e.index.mapper since it's never used outside of the Mapping?

I don't think I can do that. It will probably be needed in QueryBuilders.

[nknize]

It will probably be needed in QueryBuilders.
Okay, let's do it in a separate PR then when we refactor the queries.

[nknize]

should we just use equalsIgnoreCase instead of transforming the type string toLowerCase?