Add LEAKPROOF indication in functions

[strk]

The LEAKPROOF keyword is supported since PostgreSQL 9.2, which is our minimum requirement. By default all functions are created as NOT leakproof, meaning they cannot be used in views with "security barrier" option.

We might want to tweak that definition carefully looking at each of the functions.

See ​https://www.postgresql.org/docs/9.2/static/sql-createfunction.html

[komzpa]

Anything calling GEOS is not going to be leakproof, as GEOS tends to raise exceptions with 'invalid intersection at coordinate'. So some kind of 'take invalid geometry and try to intersect it with the world' with long enough bisection lets you get geometry out of db even if it's behind security barrier.

[robe]

Milestone renamed

[robe]

I think all the functions that back operators we can consider leak proof since they don't involve GEOS or GDAL. Probably many of the geography ones except ST_Transform related are leak proof.

I'll slate this for 2.5, seems like we should be able to do for some.

[savv]

It would be great if geometry_overlaps (and by extension, the && operator) could be made leakproof.

This would allow VIEWs with RLS policies or with a security_barrier to make effective use of geometry indices, which is currently not possible.

[robe]

we discussed this in code sprint and much more involved than what I had originally thought and not a highly asked for request so moving back to fundme