The implementation of innodb_undo_log_truncate=ON in trx_purge_truncate_history() is interfering with log checkpoint and page write performance.

Before MDEV-13564, we used the MySQL 5.7 implementation, which would force a full flush of the entire buffer pool and a sharp log checkpoint. In MDEV-13564 we changed it so that only the pages of the being-truncated undo tablespace would be removed from the buffer pool, but no log checkpoint would be needed.

There is a less intrusive, lazy approach: We can actually let the 'garbage' undo log pages remain in the buffer pool, just like we do on DROP TABLE or DROP INDEX or when freeing pages in any operation: Simply, if the newest modification to a page (FIL_PAGE_LSN) is older than the LSN of the latest tablespace rebuild, we will discard the page, just like in MDEV-15528 we do for pages whose underlying file page has been freed. With this approach, there is no need for trx_purge_truncate_history() to traverse the buffer pool.

For the similar case of shrinking the InnoDB system tablespace (MDEV-14795), there would not be a complete tablespace rebuild (like there is with innodb_undo_log_truncate=ON), so we must only discard pages that are beyond the end of the current tablespace size; their FIL_PAGE_LSN must be older than the latest LSN of shrinking the FSP_SIZE. I think that we can do that by relaxing the logic around invoking fil_invalid_page_access_msg() in fil_space_t::io().