feat(server): faster geodata import

[mertalev]

Description

This PR makes a number of optimizations to make the geodata import faster.

• Import into a fresh new table rather than one with existing rows and indices.
• Import without transaction overhead thanks to the above, only at the end to atomically drop the old table and rename the new one.
• Import without indices, then add them at the end.
• Merge generated column + index into a single expression index
  • This uses the index in testing
• More concurrency, more batching
• Unlogged table to avoid WAL overhead; this is static, disposable content where failure just means nuking the table anyway
• Explicitly set max fillfactor for indices as this is a static table

Also changes the serial column in the natural earth table to a generated identity column. This is both needed for the atomic table rename/drop to work and follows official recommendations to avoid serial.

Testing

These changes made the import go from 18s on an SSD to 8s 6.5s. The impact of this change will be especially noticeable on hard drives and other slow media.

[mertalev]

The only thing I am not sure about is creating the indexes afterwards. In my testing previously that was a good bit slower in a resource constrained environment.

It's faster to do it at the end by about 800ms from my testing. It's also better in that it lets us set fillfactor to 100 - it doesn't play nicely with inserts.

I'd be interested to learn why we need a public version of the function for it to be indexable...

I kept getting the type "earth" does not exist error when I tried to use ll_to_earth for the expression index. I'm guessing it's something to do with the search path being different during index creation than in normal queries. A neat benefit of using the explicit version is that we might not need the sed hack for backups anymore.