make update_view for materialized views create less downtime

[Roguelazer]

Right now, update_materialized_view results in a DROP MATERIALIZED VIEW followed by a CREATE MATERIALIZED VIEW with the new version; if the view is large, this can result in substantial downtime, since the drop acquires an ACCESS EXCLUSIVE lock on the view and prevents any queries from running.

Another option would be to do CREATE MATERIALIZED VIEW {name}_tmp ; ALTER MATERIALIZED VIEW {name} RENAME TO {name}_old ; ALTER MATERIALIZED VIEW {name}_new RENAME TO {name} ; DROP MATERIALIZED VIEW {name}_old. This results in negligible downtime, but costs twice the disk space. A further improvement could be to optionally run the (potentially expensive, disk-blocking) DROP in a different transaction if you pass an argument like 'i_will_clean_up_myself: true`, but in my experimentation, just doing it this way takes some expensive matview migrations from minutes of downtime to fractions of a second.

I've attached a PR for this behavior.

[derekprior]

I really like this idea and have manually done the same many years ago when dealing with a project that used materialized views heavily.

We'll need to be cognizant of things like view and index name length limits. I see there's a PR already associated to this. I likely won't be able t have a look until I'm back from vacation but just wanted to say I'm generally in support of the idea.