Polygon query for geo_point field should pass the multi-polygon to LatLonPoint

[mikemccand]

This is a follow-on to #20315, where we cutover to LatLonPoint for faster geo shape filtering.

But we still make a big BooleanQuery when a multi-polygon (a union of top-level polygons, with or without internal holes) is passed.

This is in general far slower than passing the entire multi-polyon to LatLonPoint.

[nknize]

I must've had a mental moment here. At the moment the geo_polygon query is naive. It does not support multi polygons or polygons with holes. It only supports an array of points defining a polygon shell. Only geo_shape query supports the Russian polygon. Changing geo_polygon to support complex shapes over geo_point types is on my todo list, but the shape validation phase needs to be sped up first.

That being said, rewriting a boolean query containing only geo_polygon queries to a LatLonPoint.newPolygonQuery would be a nice to have, but I think too difficult? and probably unnecessary since I'm working to refactor geo_shape to a BKD based encoding anyway.

[mikemccand]

Hmm I see. So users today must parse the polygon client side and build up their own (slow) BooleanQuery?

It seems like we should just improve geo_polygon to accept multi polygons, polygons with holes, etc., since Lucene's LatLonPoint does, and does so very efficiently? Or maybe we add a new geo_multipolygon query?

I agree we shouldn't invest in rewriting BQ automagically ... better to provide the right query to begin with.

[nknize]

Or maybe we add a new geo_multipolygon query?

I like this approach. Its straight forward and easy to implement and maintain.

[imotov]

We should probably revisit this after #32039 since we are changing quite a bit there.

[iverase]

Superseed by #48928