Re-apply DROP DATABASE getting interrupted fix and adapt for MPP

In CBDB, DROP database is hazardous in few kill-9 scenarios. Most of them are already fixed in PostgreSQL, so bring this fix to our fork. Additional change here required to move DROP DATABASE on QE dispatch AFTER marking database as invalid on QD, otherwise we can get in case where QD did not mark database as invalid, and allows connections, while QE already removed datadirs. FAULT-INJECTION test hits this (without code fix)

This is re-apply of https://git.postgresql.org/cgit/postgresql.git/commit/?id=c66a7d75e652801043ece99b6a8f89fd9513eaaa with additional cbdb fixes & tests

Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.

To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.

An invalid database cannot be connected to anymore, but can still be
dropped.

Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.

Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.

In cloudberry, we also move segment DDL dispach after pg_database tuple
transaction commit, otherwise, if killed, segments will already drop
thier datadirs, while QD not.

Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Co-authored-by: reshke <reshke@double.cloud> (Cloudberry part)
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions