Cut over geo_point field and queries to new LatLonPoint type

[nknize]

This PR cuts over geo_point fields to use Lucene's new point-based LatLonPoint type for indexes created in 5.0. Indexes created prior to 5.0 continue to use their respective encoding type. Below is a description of the changes made to support the new encoding type:

• New indexes use a new LatLonPointFieldMapper which provides a parse method for the new type
• The new LatLonPoint parse method removes support for deprecated lat_lon and geohash parameters
• Backcompat testing for deprecated lat_lon and geohash parameters is added to all unit and integration tests
• LatLonPointFieldMapper provides DocValues support (enabled by default) which uses Lucene's new LatLonDocValuesField type
• New LatLonPoint field data classes are added for aggregation support (wraps LatLonPoint's Numeric Doc Values)
• MultiFields use the geohash as the string value instead of the lat,lon string. This makes it easier to perform geo queries on the geohash instead of a useless lat,lon comma delimited string.

Removed Features:

• With the removal of geohash indexing, GeoHashCellQuery support is removed for all new indexes (still supported on existing indexes)
• LatLonPoint does not support a Distance Range query because it is super inefficient. Instead, geo_distance_range queries should be accomplished using either the geo_distance aggregation, sorting by descending distance on a geo_distance query, or a boolean must not using the excluded distance (distance_range query was syntactic sugar for this).

closes #20314

[clintongormley]

@colings86 @rjernst @mikemccand please could you review this - @jpountz is away

[mikemccand]

Maybe change these boilerplates to a real javadoc?

[mikemccand]

Thanks @nknize, I looked at the Lucene usage here and left a few small comments.

Are you planning on exposing LatLonPoint.newPolygonQuery and .newDistanceSort too?

LatLonPoint also offers very fast nearest neighbor search, but we should probably do that separately.

[nknize]

Thanks for the review @mikemccand! I'll address the feedback and update the PR.

Are you planning on exposing LatLonPoint.newPolygonQuery and .newDistanceSort too?

newPolygonQuery does need to be added to this PR, and I'll look at adding newDistanceSort but I don't think that one's a blocker?

I'm also planning to add nearest neighbor in another PR,.

[mikemccand]

newPolygonQuery does need to be added to this PR, and I'll look at adding newDistanceSort but I don't think that one's a blocker?

++, these both can be done separately.

[mikemccand]

The Lucene parts LGTM, thanks @nknize!

I do think .newDistanceSort is important since the optimized implementation in Lucene is extremely fast, but this can be done separately.

[s1monw]

this must be updated to onOrBefore

[s1monw]

this look great, @nknize I notice that this removes tons of docs but doesn't add new docs how is this going to work? do we have to add docs later?

[s1monw]

test this please

[nknize]

Thanks @s1monw! I talked to @clintongormley about updating docs in a separate PR to make it easier to review.

[mikemccand]

@nknize I think the newPolygonQueryhere is inefficient in the multi-polygon case? It looks like (correct me if this is wrong!!) if e.g. a user queries on the Russia polygon (many top level polygons, each with many holes) that ES will make a very large BooleanQuery as a result, instead of passing that multi-polygon to LatLonPoint (which is quite a bit more efficient)?

Should I open a new issue to fix this?

[nknize]

Nice catch @mikemccand I agree the multi-poly should be passed to LatLonPoint. Go ahead and open the issue and I'll make the change. Thx!

[mikemccand]

Thanks @nknize ... I opened #20789.