Write-ahead logging is broken for freed pages

MDEV-15528 implemented an optimization: pages that have been marked as freed will not be written back to data files. Unfortunately, this optimization violates the write-ahead logging protocol, because we fail to ensure that all log up to the freeing of the page has been durably written before we elide the write of the data page.

If InnoDB is killed before the log for freeing a page was durably written, crash recovery could fail because it would read an older version of the data page and attempt to apply log records that are for a newer version of the page.

We can observe some occasional recovery test failures that could be explained by this, such as the following:

atomic.alter_table 'innodb'              w1 [ fail ]  Found warnings/errors in server log file!

        Test ended at 2023-01-10 11:25:39

line

2023-01-10 11:24:24 0 [ERROR] InnoDB: Corrupted page [page id: space=228, page number=0] of datafile './test/t1.ibd' could not be found in the doublewrite buffer.

The scenario that I have in mind would be fixed by making buf_page_free() mark the freed block as modified in the mini-transaction, and buf_flush_page() check that everything up to the FIL_PAGE_LSN of the page has been durably written to the redo log. After first change, that field would be updated by buf_flush_note_modification(), which is invoked by mtr_t::commit().