Improve geos multipolygon creation performance

[Quiwin]

Replace a manual validity check on MultiPolygon, which was iterating on
each polygon combination, by a direct call of geos isValid.

Summary

Hello !

MultiPolygon creation was slower than expected on large MultiPolygon, it was due to an old check for validity which manually iterated on every polygon combination of the given multiPolygon.
Now directly call geos to check for validity.

Other Information

Tested with above geojson:

geojson = IO.read("france.geojson")
require 'micro_bench'
MicroBench.start;RGeo::GeoJSON.decode(geojson, geo_factory: RGeo::Cartesian.preferred_factory); puts "#{MicroBench.duration.round(2)} sec"

Before: 1.95 sec
After: 0.35 sec

I couldn't find the exact geos issue it tried to avoid
but I dont think there is much risk since the previous code written to circumvent it was more than 11 years ago c44767e

Thanks!

[BuonOmo]

Looking at history of the IsValidOp.h I don't see the point of that comment or code either.

@Quiwin knowing your sources, I guess your france.geojson polygon is this one.

I'm more in favor than not : it seems genuinely better.

@keithdoggett do you know the historical reason there, or do you think we should ping Daniel ? Also about the failing tests, we should work on that asap !

[BuonOmo]

One small cosmetic change that feels clearer !

Suggested change

	if (collection &&
	type == GEOS_MULTIPOLYGON
	&& (factory_data->flags & 1) == 0
	&& (GEOSisValid_r(geos_context, collection) == 0)) {
	if (collection
	&& type == GEOS_MULTIPOLYGON
	&& !(factory_data->flags & 1)
	&& !GEOSisValid_r(geos_context, collection)) {

[keithdoggett]

Looks good! I'm not sure of the historical purpose of those extra checks. It seems that GeosIsValid supports all geometries, and this isn't used to identify a specific issue with validity since it doesn't do anything differently based on which check it fails.

@BuonOmo are all of the checks failing because of a floating-point comparison issue? I think I have a fix for that in the v3-dev branch we can probably cherry-pick.

[BuonOmo]

As discussed over the phone with @keithdoggett, we should merge this one into the v3-dev to avoid having to backport of all @keithdoggett's work on floating point issues. @Quiwin could you rebase on this branch and we'll merge it there.

That will be one more great reason for using rgeo 3.0 😄

And could you also add a note to the changelog ? (History.md file)

[Quiwin]

As discussed over the phone with @keithdoggett, we should merge this one into the v3-dev to avoid having to backport of all @keithdoggett's work on floating point issues. @Quiwin could you rebase on this branch and we'll merge it there.

That will be one more great reason for using rgeo 3.0 😄

And could you also add a note to the changelog ? (History.md file)

@BuonOmo Done :)