upgrade-postgresql: Prevent upgrades if /etc/zulip/zulip.conf is wrong.

If the `postgresql.version` in `/etc/zulip/zulip.conf` is out of date
or wrong, upgrading to the actual current version would drop your
production database without prompting.  While we do document taking a
Zulip backup (which includes a database backup) before running
`upgrade-postgresql`[^1], not everyone does so, with possibly
catastrophic consequences.

Do a true end-to-end check of the version in `/etc/zulip/zulip.conf`
by asking Django to query the database for its version, checking that
against the configured value, and aborting if there is any
disagreement.

[^1]: https://zulip.readthedocs.io/en/latest/production/upgrade.html#upgrading-postgresql

scripts/setup/upgrade-postgresql

@@ -26,6 +26,27 @@ if [[ "$UPGRADE_TO" -lt "$UPGRADE_FROM" ]]; then
     exit 1
 fi
 
+# Verify that the version in /etc/zulip/zulip.conf is the version that
+# Django actually stores its data in.  We can only do that if the
+# database server is on the same host as the application server.
+if [ -d /home/zulip/deployments/current ]; then
+    DATA_IS_IN=$(su zulip -c '/home/zulip/deployments/current/manage.py shell -c "from django.db import connection; print(int(connection.cursor().connection.server_version/10000))"')
+
+    if [ "$UPGRADE_FROM" != "$DATA_IS_IN" ]; then
+        cat <<EOF
+
+/etc/zulip/zulip.conf claims that Zulip is running PostgreSQL
+$UPGRADE_FROM, but the server is connected to a PostgreSQL running
+version $DATA_IS_IN.  Check the output from pg_lsclusters to verify
+which clusters are running, and update /etc/zulip/zulip.conf to match.
+
+In general, this results from manually upgrading PostgreSQL; you
+should use this tool for all PostgreSQL upgrades.
+EOF
+        exit 1
+    fi
+fi
+
 set -x
 
 "$ZULIP_PATH"/scripts/lib/setup-apt-repo