2 GEOS specific Memory leaks when using spatialite

[mj10777]

Here is a summery of 2 small memory leaks that occur when using spatialite:

​https://www.gaia-gis.it/fossil/libspatialite/info/9183e58794

Valgrind messages

by 0x9279260: geos::geom::GeometryFactory::GeometryFactory() (GeometryFactory.cpp:86)
by 0x927B764: geos::geom::GeometryFactory::getDefaultInstance() (GeometryFactory.cpp:728)
by 0x740CA6B: GEOS_init_r (geos_ts_c.cpp:165)

summery of my assumptions ^{(which may be wrong)}

The GEOS structure, created in GEOS_init_r and deleted in finishGEOS_r, is called GEOSContextHandle_HS and contains 3 pointers:

const GeometryFactory *geomFactory;
void *noticeData;
void *errorData;

This structure is deleted in geos-3.5.0/capi/geos_ts_c.cpp:finishGEOS_r(GEOSContextHandle_t extHandle)
without any checking if these pointer need to be freed.
geomFactory is the pointer that seems to be causing the memory leaks

reproduction ^{(select_tables.sql contains 'SELECT name FROM sqlite_master;')}

valgrind -v --leak-check=full --show-leak-kinds=all spatialite memory_leak.db < select_tables.sql

---

I attempted to find a way to resolved this, but the solution that worked well for spatialite/rasterlite2 (first part), caused very bad side effects (crashing QGIS when called from within gdal-ogr) in other applications (second part).

Sandro Furieri has confirmed the existence of this minor leak.

It is, however, when using rasterlite2, the last leak from a spatial-related projects, libpixman being then being the only cause of leaks when using both of the libraries togeather. So it would be nice to get rid of this.

[strk]

One way to resolve this would be for the re-entrant interface not to use the lazily-created GeometryFactory singleton but rather use an explicitly created / explicitly deleted GeometryFactory.

Doing so won't guarantee that the singleton won't be used by some internal operation, so the singleton leak is still pending as an issue.

The singleton changed from a stack allocated to an heap-allocated objet with r3632, to fix #540, so if it has to change, #540 should be checked for not being still a problem

[strk]

I turns out, this is a duplicate of #587