Skip pg_database.dathasloginevt cleanup on standby

Skip pg_database.dathasloginevt cleanup on standby

EventTriggerOnLogin() tries to clear pg_database.dathasloginevt when
the database no longer has any login event triggers but the flag is
still set.  To make that safe against concurrent flag setters, it
takes a conditional AccessExclusiveLock on the database object.

On a hot standby, that lock acquisition fails outright with

  FATAL:  cannot acquire lock mode AccessExclusiveLock on database
          objects while recovery is in progress

because LockAcquireExtended() refuses locks stronger than
RowExclusiveLock on database objects during recovery.  The standby
already replays the flag's value from the primary, so the dangling
flag is the result of replaying a state in which the primary had
already dropped its login event triggers but not yet run a login
event trigger pass to clear the flag.  Any session connecting to the
standby in that window therefore fails to connect.

Skip the cleanup on a standby.  The flag will be cleared via WAL
replay once the primary clears it on its side.

Add a recovery TAP test that reproduces the original report: create
and drop a login event trigger on the primary in one session, wait
for the standby to replay, then verify that a fresh connection to
the standby succeeds.

Backpatch to v17, where the login event triggers were introduced.

Author: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Reported-by: Egor Chindyaskin <kyzevan23@mail.ru>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
Discussion: https://postgr.es/m/19488-d7ccfca2bf6b74b0%40postgresql.org
Backpatch-through: 17