Support --without-geos switch

[robe]

This was a request from Darafei Praliaskouski (Komzpa) made on IRC on behalf of Postgres Professional (​https://postgrespro.com/)

Normally I'd laugh at such a request, but I'd like to do it for a couple of reasons especially if Komzpa is willing to put in the sweat to make it happen.

1. Postgres Professional (is lead by Oleg Bartunov and Teodor Sigaev) which many long standing folks in PostGIS community might recognize as the faces behind GiST (which makes PostGIS so fast) and Full-Text search in addition to index improvements on JSON.

Postgres Professional has contributed development to PostgreSQL (e.g. index support for regex, new work on ANSI-SQL JSON support and numerous other things too many to count)

2. They need it for a very good cause. They need a lighter-weight PostGIS that can be used easily, so they can defend the security of it to the Russian Government.

GEOS is too big of a creature for them to audit and approve.

3. I forsee this as an easy way for new developers to get up to speed contributing to PostGIS since the requirements to compile will be lower.

My proposal is as follows.

If postgis is compiled —without-geos (we assume if that config is not present then we still require geos), much like we do —without-raster, then all GEOS functions will be stubbed and throw an error, something like

Requires GEOS, you need to recompile your PostGIS with GEOS support to use this function

4. However the following function ST_Intersects will still be available, but instead of using GEOS would piggy back on _ST_DWithin, much like what geography type does already. We should do this on the C-side so no upgrading needs to be done if people recompile / —without-geos or with geos.

[pramsey]

I'm -1 on this, as I don't see the cost/benefit of it. It will certainly add a great deal of build complication to the code base, more optional code paths, complications in both ./liblwgeom and ./postgis and we get what…? There's already a PostgreSQL spatial database with limited functionality, it's called PostgreSQL. We resist complication in our code base to the point of tearing out perfectly good shims for old versions of GEOS on principle, but… we'll add a huge complication for a use case that so far just one institution wants? Bring us something worth trading for that complication, right? As it stands, the trade-off doesn't seem worth it.

[robe]

note I changed this to a Fund Me instead of a wontfix since pramsey argued if "there is something worth trading" so not a complete dismissal.