Suboptimal or dead code at server startup

MDEV-14425 introduced some dead code. I found it via an assertion failure that occurred in a modified version of the MDEV-37949 development branch on my local system. Here is an example of the dead code; there are several occurrences:

diff --git a/storage/innobase/buf/buf0flu.cc b/storage/innobase/buf/buf0flu.cc

index 4e9f1e015ba..aff3ea82d66 100644

--- a/storage/innobase/buf/buf0flu.cc

+++ b/storage/innobase/buf/buf0flu.cc

@@ -2188,9 +2188,7 @@ ATTRIBUTE_COLD void buf_flush_wait_flushed(lsn_t sync_lsn) noexcept

 ATTRIBUTE_COLD void buf_flush_ahead(lsn_t lsn, bool furious) noexcept

 {

   ut_ad(!srv_read_only_mode);

-

-  if (recv_recovery_is_on())

-    recv_sys.apply(true);

+  ut_ad(!recv_recovery_is_on());

   DBUG_EXECUTE_IF("ib_log_checkpoint_avoid_hard", return;);

At the start of the function recv_sys_t::apply(), we have the assertion mysql_mutex_assert_owner(&mutex) that would always fail if the above call was invoked. Note: in MariaDB Server 10.6, recv_sys_t::apply() will acquire recv_sys.mutex by itself.

The server bootstrap and startup can be simplified further: The MDEV-38595 fix can be refined so that buf_pool_invalidate() (which empties the buffer pool) only needs to be called during multi-batch crash recovery. The function buf_flush_sync() can be replaced with buf_flush_sync_batch(LSN_MAX), and we do not need to invoke it during server initialization. Third, the logic related to creating or rebuilding the redo log at startup can be simplified.