Re: Fixing the btree_gist inet mess

Here's a v2 patchset that tries to address all the discussion so far.

The principal change from v1 is that I made a rolled-up
btree_gist--1.9.sql script in which the problem opclasses are not
marked DEFAULT.  So that version can be installed without any
hack in DefineOpClass.  This answer is much better than my v1 in
terms of having a clean way to describe the change in the module,
too.

We still need a hack for binary-upgrade mode though, since pg_dump
will dump the CREATE OPERATOR CLASS commands with DEFAULT if it's
looking at an old copy of btree_gist.  (I looked at putting said hack
into pg_dump instead of the server, but it didn't seem like an
improvement.  Heikki's idea of making pg_dump --binary-upgrade
dump "CREATE EXTENSION btree_gist" seemed much messier than this,
too.)

Because I didn't change DefineOpClass's behavior when
!IsBinaryUpgrade, any attempt to install a pre-1.9 version of
btree_gist will now fail.  So we could remove btree_gist--1.2.sql
as well as btree_gist--1.0--1.1.sql and btree_gist--1.1--1.2.sql
without cost.  (I've not done that here, as it would just bloat the
patchset some more.)  However we should keep btree_gist--1.2--1.3.sql
and later delta scripts, so that users can update old definitions of
the module to 1.9 after a pg_upgrade.

I've also fixed up the cross-version-upgrade tests and written
some documentation.

One point perhaps worth mentioning here is that it works to
copy btree_gist--1.8--1.9.sql into a v18 installation and
issue
	ALTER EXTENSION btree_gist UPDATE TO '1.9';
after which pg_upgrade will let you upgrade your old indexes
without complaint, because pg_dump will now do the right things.
I did not document this because (a) it does not work in anything
before v18 due to lack of btree_gist 1.8, and (b) we don't want
to encourage people to stay on the old opclasses in v19.  But
perhaps somebody would find a reason to want to do this.

I'd probably squash all this into one commit at the end, but
I made it into several patches for review purposes.

			regards, tom lane