chore: Check that upgrade scripts do not diverge from a fresh install (…

…#525)

## Problem
As seen in #521, it's easy for the
upgrade scripts to diverge from a fresh installation.

## Solution
This PR adds a check to verify that the upgrade scripts do not diverge
from a fresh installation. The check uses the output of `pg_dump` as
well as a manual query of the extensions functions (these are not
included in `pg_dump`).

This PR also adds a new migration script (`pgmq--1.11.0--1.11.1.sql`) to
resolve the existing differences between the upgrade scripts and a fresh
installation.

### Summary of differences and how they were resolved
#### `pgmq.read_grouped_head`

This function only existed in the fresh install (`pgmq.sql`), so this PR
adds it via a migration file as well.

#### `pgmq._ensure_pg_partman_installed`
This method exists for both fresh installs and upgrades, but the
implementations are different. This PR updates the version in the
upgrade path to match the fresh installation.

#### `enable_notify_insert`

This function ([added
here](https://github.com/pgmq/pgmq/blob/66349cfee14ab75827eb541d36b2c84cbbb68dab/pgmq-extension/sql/pgmq--1.6.1--1.7.0.sql#L9))
originally had a single parameter but was [updated to have two
parameters](https://github.com/pgmq/pgmq/blob/66349cfee14ab75827eb541d36b2c84cbbb68dab/pgmq-extension/sql/pgmq--1.7.1--1.8.0.sql#L45)
-- the single-parameter version does not exist in fresh installs. I'm
guessing that the upgrade script was intending to replace the
single-parameter version with the two-parameter version, but `CREATE OR
REPLACE FUNCTION` does not replace an existing function if the parameter
types are different, even if the function names match, so the
single-parameter version was not removed.

This PR removes the single parameter version. This should not be a
breaking change as the two-parameter version has a default value for the
second parameter, so it can be called in the same way as the old
single-parameter version.

#### `pg_dump` output
First, there was a missing `PERFORM
pg_catalog.pg_extension_config_dump('pgmq.topic_bindings', '');` call
for the migration path. This PR adds the missing call.

Second, in the migration path, the `pgmq.notify_insert_throttle` and
`pgmq.topic_bindings` tables are created after the blanket `GRANT`s from
the fresh installation script, so they each have an extra `GRANT SELECT
ON TABLE ... TO pg_monitor;` line in the `pg_dump` output. The fresh
installation script was updated to move the blanket `GRANT`s to be
before the creation of these tables as well.

Closes #521

actions-rs/toolchain -> dtolnay/rust-toolchain (#502)

replace actions-rs/toolchain (archived) with dtolnay/rust-toolchain in
pgmq-rs's CI

update controlv version

add last_read_at (closes #466) (#471)

More details here: #466

- this PR was very much inspired by #338 (in which the `headers` column
was added)
- in `pgmq-extension/sql/pgmq.sql`: searched for all mentions of
`enqueued_at` and added `last_read_at` right after it (where it made
sense)
- in `pgmq-extension/sql/pgmq--1.8.0--1.8.1.sql`:
    - update `pgmq.message_record` to have `last_read_at` (as in #338)
    - update existing queues using a `DO $$ ... $$` block (as in #338)
- copy-paste from `pgmq-extension/sql/pgmq.sql` of all functions that
now use `last_read_at`, which are these:
        - `pgmq.read`
        - `pgmq.read_with_poll`
        - `pgmq.archive` (with overload)
        - `pgmq.create_non_partitioned`
        - `pgmq.create_unlogged`
        - `pgmq.create_partitioned`
- replace the explicit listing of all `pgmq.message_record` attributes
with `m.*`
- this was necessary because it makes sense to place `last_read_at`
right after `enqueued_at` (and before `vt`), but users who already have
the extension will instead have `last_read_at` at the end
- this change seemed ok to make because we already have precedence: we
already have some functions that return `SETOF pgmq.message_record` and
use `RETURNING *` (namely these 2: `pgmq.pop` and `pgmq.set_vt`)
- tests: not really sure how to proceed here; would be great if someone
could help with this

---------

Co-authored-by: Adam Hendel <hendel.adam@gmail.com>

Versioned docs (#482)

closes #151

Update pgmq.control1.8.1 (#473)

prep for 1.8.1 release

prep v1.8.0 release (#460)

Client-side notification tests (#434)

* add client side tests for notifications

---------

Co-authored-by: Christopher Probst-Ranly <christopher@knockturn.io>

patch extension config dump (#418)

* fix check on extension installation

* add migration sql

Make extension data pg_dumpable (#413)

* queue and archives are no longer extension member objects in order to support pg_dump. pgmq.meta now works with pg_dump


* remove membership mods

* update notice to mention no-op

* test queue and archive persist through extension drop

* add the member object modifications back to the migration