The assertion happens under BACKUP STAGE BLOCK_COMMIT, when a DDL on a
temporary table (#sql-xxx) is found.

Apparently, assumption that all DDLs are blocked under FTWRL does not
hold for BACKUP STAGE, and temporary tables can still have ALTERs

The fix is to relax the assertion, and only check for opt_no_lock if
backup is *really* inconsistent, i.e either optimized DDL or CREATE/RENAME
are done on the tables that were not skipped during backup.