Add configurable backend cleanup and Greengage integration tests

[vadv]

Add two settings: cleanup_server_connections modes off, adaptive, always, and cleanup_server_query. Both work in [general] and per pool.

• adaptive (default). Built-in cleanup SQL runs only after a tracked session state change.
• always. cleanup_server_query runs on every checkin of a backend that served a client. The query is required.
• off. No session cleanup. ROLLBACK for an open transaction still runs.

Legacy true and false mean adaptive and off.

cleanup_server_query replaces the built-in RESET ROLE / RESET ALL / DEALLOCATE ALL / CLOSE ALL sequence. A good example is PgBouncer's default server_reset_query: DISCARD ALL. Validation checks the pair as a whole: always requires a query. adaptive rejects a query. A pool without its own settings inherits both from [general].

Adaptive detection

The built-in cleanup tracks these statements and answers with cleanup SQL:

Statement	Cleanup
SET	RESET ALL
DECLARE cursor	CLOSE ALL
SQL PREPARE	DEALLOCATE ALL
LISTEN	UNLISTEN *
CREATE TEMP TABLE	DISCARD TEMP

Every cleanup batch also releases advisory locks with pg_advisory_unlock_all().

Motivation:

• SQL PREPARE and an extended-protocol Parse share one statement namespace. Without tracking, the next client on the same backend failed with 42P05 duplicate_prepared_statement.
• A pooled backend's socket is not read. Queued NotificationResponse messages reached the client that checked the backend out next.
• A temporary table survived checkins in both pooling modes.

Not tracked: SELECT ... INTO TEMP and CREATE TEMP TABLE AS SELECT. Current PostgreSQL completes them with the inner query's tag. Temporary objects inside functions carry no tag. Use always with suitable SQL for these.

Behavior

• A failed cleanup retires the backend. Responses already sent to the client stay delivered, including a successful COMMIT.
• A NOTICE from the cleanup query goes to the client. It is not an error and does not retire the backend.
• A client RESET or DISCARD ALL suppresses built-in cleanup in adaptive. It never suppresses always.
• A session-level advisory lock survives only until a cleanup batch runs. In transaction pooling, treat advisory locks as per-transaction.

Tests

• BDD scenarios cover the leaks before the fix: temp tables, LISTEN subscriptions, cross-client notifications, SQL PREPARE collisions, advisory locks.
• Other scenarios cover config inheritance and reload, prepared statements, startup parameters, asynchronous protocol boundaries, and cleanup metrics.
• make test-greengage runs @greengage scenarios on a pinned Greengage 7.5 image with one coordinator and two primary segments. These tests also run in CI.

Scope

• Runtime changes: 18 files, +693 / −105 lines. Tag classifier and cleanup batch, config parsing, backend retire path, the pg_doorman_server_cleanup_total metric.
• Tests: 24 files, +2770 / −56 lines. BDD features and steps, plus in-file unit tests.
• Documentation: 10 files, +175 / −102 lines. Pool reference, concept pages, config examples generator, changelog.

Other changes

• New metric pg_doorman_server_cleanup_total with labels user, database, result (ok / error).
• Updated pg_doorman.toml, pg_doorman.yaml, and the English and Russian documentation.
• Launchpad publishing now runs only for releases.
• Removed a missing frontend-file dependency that caused repeated Rust rebuilds.

Upgrade notes

1. The default behavior does not change.
2. Old configs with true and false keep working.
3. SHOW and config dumps omit pool-level cleanup_server_connections when the pool does not set its own. Treat the field as optional in parsers.
4. Greengage users: set cleanup_server_connections = "always" and a cleanup query with DISCARD TEMP. Greengage DISCARD ALL leaves temporary tables on segments. See the pool reference for an example.
5. Advisory locks are released by every cleanup batch in adaptive mode. If a client holds session-level advisory locks across transactions, use session pooling or off.
6. In transaction pooling a temporary table lives for one transaction: the cleanup follows the CREATE at the next checkin. Keep a transaction open across the statements that use the table, or use session pooling.