Fix invalid database resulting from failed DROP DB (#5423)

## Problem
If the control plane happened to respond to a DROP DATABASE request with
a non-200 response, we'd abort the DROP DATABASE transaction in the
usual spot. However, Postgres for some reason actually performs the drop
inside of `standard_ProcessUtility`. As such, the database was left in a
weird state after aborting the transaction. We had test coverage of a
failed CREATE DATABASE but not a failed DROP DATABASE.
 
## Summary of changes
Since DROP DATABASE can't be inside of a transaction block, we can just
forward the DDL changes to the control plane inside of
`ProcessUtility_hook`, and if we respond with 500 bail out of
`ProcessUtility` before we perform the drop. This change also adds a
test, which reproduced the invalid database issue before the fix was
applied.

test_runner/regress/test_ddl_forwarding.py

@@ -211,4 +211,12 @@ def test_ddl_forwarding(ddl: DdlForwardingContext):
         ddl.wait()
 
     ddl.failures(False)
+    cur.execute("CREATE DATABASE failure WITH OWNER=cork")
+    ddl.wait()
+    with pytest.raises(psycopg2.InternalError):
+        ddl.failures(True)
+        cur.execute("DROP DATABASE failure")
+        ddl.wait()
+    ddl.pg.connect(dbname="failure")  # Ensure we can connect after a failed drop
+
     conn.close()