Submitted by: @hvlad

Some clauses of ALTER DATABASE statement requires to update row in RDB$DATABASE:
SET DEFAULT CHARACTER SET, SET LINGER, DROP LINGER.

Other clauses doesn't requires to update RDB$DATABASE:
BEGIN|END BACKUP, ENCRYPT, DECRYPT, etc

Internally, engine runs such UPDATE despite the kind of clause specified by the user.
It is necessary to prevent concurrent run of ALTER DATABASE statements by parallel transactions.

Unfortunately, such dummy update blocks other transactions which reads RDB$DATABASE in READ COMMITTED NO RECORD VERSION mode.
Usually such blockage is very short, but in case of ALTER DATABASE END BACKUP it could be up to tens of minutes.

For example: user complains that isql can not connect with isql to the database while ALTER DATABASE END BACKUP is running.
Actually, isql connects successfully, but it reads RDB$DATABASE itself right after attachment (using READ COMMITTED NO RECORD
VERSION WAIT transaction) and waits until ALTER DATABASE END BACKUP commits.

The improvement is to avoid dummy update of RDB$DATABASE when possible and use implicit lock to prevent concurrent run
of ALTER DATABASE statement.

Commits: 62735f4 6988a98 73cdac3 c5667b3