Fix VACUUM's tests to see
whether it can update relfrozenxid (Andres Freund)

In some cases VACUUM (either
manual or autovacuum) could incorrectly advance a table's
relfrozenxid value, allowing
tuples to escape freezing, causing those rows to become
invisible once 2^31 transactions have elapsed. The
probability of data loss is fairly low since multiple
incorrect advancements would need to happen before actual
loss occurs, but it's not zero. Users upgrading from
release 8.4.8 or earlier are not affected, but all later
versions contain the bug.

The issue can be ameliorated by, after upgrading,
vacuuming all tables in all databases while having
vacuum_freeze_table_age set to zero. This will fix
any latent corruption but will not be able to fix all
pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has
executed fewer than 2^31 update transactions in its
lifetime (check this with SELECT
txid_current() < 2^31).

In some cases, the system would use the simple GMT
offset value when it should have used the regular timezone
setting that had prevailed before the simple offset was
selected. This change also causes the timeofday function to honor the simple
GMT offset zone.