Remove need for shared library PostgreSQL functions

[zerebubuth]

This repo contains code for three functions to be loaded into PostgreSQL as a shared library:

1. maptile_for_point, which is used only by the /changes API call. This API call is little-used and IMHO should be deprecated and removed. However, even now it's hardly on the hot path for most development activities.
2. tile_for_point, which is used only in migrations. At this point, it seems unlikely that anyone will be doing a migration on existing data which would call this function (most developers will be running migrations on an empty database, to set it up).
3. xid_to_int4, which is only used for replication using Osmosis and isn't used in the Rails code at all. Hopefully this will be replaced Real Soon Now, but until then it's a quite advanced feature that most developers won't need.

Therefore, this patch proposes to replace the above three shared library functions with SQL implementations of the first two. These are much slower - by a factor of about 30x, however this makes no difference when they're run on a completely empty database. In return, we're able to drop a dependency on the PostgreSQL server development package, and clean a few lines out of the installation instructions.

It's still possible to make and install the shared library functions, and I've included instructions about how to do that - although it shouldn't be necessary for the vast majority of openstreetmap-website developers.

[mmd-osm]

Good idea, I was about to propose the same, but haven't gotten to it. 👍 This would greatly simplify #2272 where those shared libs already caused quite some headache.

Also, agree on deprecating /changes. It's totally undocumented, and a pretty obscure feature.

[gravitystorm]

This is great and I'm all for it. It's not only better for developers, but opens up new installation environments where users might not be able to load/compile shared libraries.

I've added some minor notes on the documentation inline - I'm just trying to streamline the first-install experience for new developers. Additionally:

• I think it's worth adding a line to the "Production Deployment" section of CONFIGURE.md
• I'd like @tomhughes to confirm if he's happy with this PR too.

[mmd-osm]

This sounds a bit as if there was a non-shared library version of the xid_to_int4 function available, which isn't the case. To make this a bit clearer maybe state that diff replication depends on a function xid_to_int4, which is only being made available as a shared library. Additional bonus information would be to state that this function is only supported up to and including Postgres 9.5.

[tomhughes]

Well the point is that the xid_to_int4 function is something that as far as I know only we use and we would simply arrange to carry on using the 3GL version without it being part of the standard installation.

[mmd-osm]

I wasn't even aware of a 3GL version, but you're right: osmosis ships one: https://github.com/openstreetmap/osmosis/blob/master/package/script/contrib/apidb_0.6_osmosis_xid_indexing.sql - but I guess the same limitations for USING btree ((xid_to_int4(xmin))); apply on 9.6+ as for the C-version, right?

[zerebubuth]

To try and avoid confusion, I've changed that line in 7fb5bca to explicitly say there's no pure SQL version of xid_to_int4.

[grischard]

Just out of curiosity: what did /changes do?

[tomhughes]

It gets a list of tiles at a given zoom level that have changed in a given time period - by default if does z12 for the last hour but both can be changed.

It only looks at nodes though so it won't notice changes to ways or relations that cross a tile.