Reorganize spatial_ref_sys

[strk]

The current strategy of mixing custom and system records in the same spatial_ref_sys table is a bit complex and prone to errors on upgrade, whereas users changing a system record would see those records changed on upgrade.

This ticket is to find a cleaner solution.

My proposal is to turn spatial_ref_sys into a view and provide spatial_ref_sys_postgis containing the official entries and a spatial_ref_sys_user to contain custom/overridden entries.

The view would pick records from spatial_ref_sys_user in preference to those in spatial_ref_sys_postgis.

I've given this solution a try and with a non-materialized view the performance hit is that a _user table with ~100 overrides makes a query for a single SRID 2.5x slower than directly fetching that record from a table (but it's still around 2ms on my laptop).

Test of my implementation is in ​https://gitlab.com/postgis/postgis/-/merge_requests/57

[strk]

The situation depicted in #4405 could be a good one to test performances (index on ST_Transform)

[strk]

So after trying to implement the view idea I'm really appreciating the simplicity of Regina's solution of just adding an is_custom boolean column. Such column could determine whether or not the entries are reset on update or not (only non-custom entries should be reset) and whether or not they are dumped by pg_dump I guess (custom entries should be dumped).

During the excercise I've seen that at least gitlab-ci bot is not testing much about spatial_ref_sys because it succeeded way too easily …

[strk]

I've pushed a "spatial-ref-sys-view" branch to the official repository for bots to check (and humans too). Please let me know what you think about it.

[pramsey]

I remain skeptical of the churn/reward ratio of mucking with spatial referencing anymore than is absolutely necessary.