rgw/sfs: use sqlite3 backup API to create temp db

[tserong]

It's not safe for DBConn::check_metadata_is_compatible() to make a copy of the database file while it's already open via SQLite, because the close() that happens after the file is copied cancels all POSIX advisory locks, which can later lead to database corruption. For details, see:

https://www.sqlite.org/howtocorrupt.html#_posix_advisory_locks_canceled_by_a_separate_thread_doing_close_

This change replaces fs::copy() with use of SQLite's Backup API (https://www.sqlite.org/backup.html) which is safe to use with open databases.

Fixes: https://github.com/aquarist-labs/s3gw/issues/702

[irq0]

An alternative might be sqlite_orm's make_backup_to. But that would have go through a copy of Storage via get_storage instead of first_db_conn. Benefit would be simpler error handling - sqlite_orm throws on non SQLITE_OK return codes.

Is it safe to ignore the returncodes of sqlite3_backup_step and sqlite3_backup_finish?

[tserong]

An alternative might be sqlite_orm's make_backup_to. But that would have go through a copy of Storage via get_storage instead of first_db_conn. Benefit would be simpler error handling - sqlite_orm throws on non SQLITE_OK return codes.

I didn't know about that :-) I don't have a strong preference for any particular implementation, and I don't think it makes much practical difference whether it uses get_storage or first_db_conn (this thing runs once at startup).

Is it safe to ignore the returncodes of sqlite3_backup_step and sqlite3_backup_finish?

Yeah, according to https://www.sqlite.org/backup.html and https://www.sqlite.org/c3ref/backup_finish.html if these fail an error code will be attached to the destination database, which will then be picked up when we call sqlite3_errcode(temporary_db);