Whitelist geo methods for Painless

[jdconrad]

This change makes several classes relating to geo along with relevant methods and fields available as part of the standard whitelisting in Painless (across all contexts). This also adds the ability to add read-only non-static fields as part of a whitelist with an included test.

The following classes are added:

• org.apache.lucene.geo.Rectangle
• org.elasticsearch.common.unit.DistanceUnit
• org.elasticsearch.common.unit.DistanceUnit$Distance
• org.elasticsearch.common.geo.GeoPoint
• org.elasticsearch.common.geo.GeoDistance
• org.elasticsearch.common.geo.GeoUtils

Closes #24946

[elasticmachine]

Pinging @elastic/es-core-infra

[jdconrad]

@nknize Hey Nick, would you please take a look at the methods I've added to the whitelist here and let me know if I'm missing anything that should be available or I've added things that don't make sense? Thanks in advance!

[jdconrad]

@martijnvg Please hold off on any final review for now as after speaking briefly with @rjernst I want to get some more feedback on what contexts should actually have these methods and if the method set is correct. Any thoughts on the contexts or method set though?

[martijnvg]

@jdconrad The method set looks good to me. I think the following contexts should at least have these methods: filter, score, field and aggs.

[jdconrad]

@martijnvg Hey Martijn, I've limited the contexts that geo can be used in, so this is ready for a final review now. Thank you!

[martijnvg]

@jdconrad This change looks good. Like we discussed today, it would be great to have some unit tests that test that these geo methods are actually available in these contexts.

[rjernst]

This is a lot of random date stuff. Can we consolidate to what users actually need? For example, there are several distance methods on different distance classes, overlapping existing distance wrapper methods (eg on ScriptDocValues.GeoPoints).

[jdconrad]

@rjernst Please tell me what you would include exactly

[rjernst]

I think what we include should be agreed on with @nknize. IMO we should reduce to a single set of distance methods/representations.

[nknize]

@jdconrad I took a quick look. Everything whitelisted in this PR make complete sense to me. My inline comments list other classes we may want to consider adding. (e.g., the new ES geo library, lucene's Polygon and GeoUtils class). Am I understanding correctly that adding these classes and methods to the whitelist enable users to access those methods in the scripts? If so then I think adding those suggested classes would be very useful.

[jdconrad]

@rjernst mentioned that some of the geo methods here might be up for refactoring soon, so I moved this back to a WIP while we come up with an appropriate plan for how to handle that situation

[jdconrad]

Had a brief meeting with @nknize and @rjernst. I'm going to close this PR for now as a lot of refactoring work is likely to occur in the near future on most of the geo classes whitelisted here. In the near term @nknize is going to add a method for bounding boxes after which we will whitelist the elasticsearch geo version of Rectangle in a new PR. GeoPoint and distance methods already exist in the standard whistelist and will be added to the API docs once the automated context API docs project is completed.