Remove bogus conditions related to not redo-logging PAGE_MAX_TRX_ID changes

InnoDB originally skipped the redo logging in page_set_max_trx_id() until I enabled it in a commit whose exact history is lost, but which was later repushed to the MySQL repository as part two commits: e76b873f24cd (present in 5.5.5 and some InnoDB Plugin for MySQL 5.1) and 509e761:

r5038 | marko | 2009-05-19 22:59:07 +0300 (Tue, 19 May 2009) | 30 lines

branches/zip: Write PAGE_MAX_TRX_ID to the redo log. Otherwise,
transactions that are started before the rollback of incomplete
transactions has finished may have an inconsistent view of the
secondary indexes.

dict_index_is_sec_or_ibuf(): Auxiliary function for controlling
updates and checks of PAGE_MAX_TRX_ID: check whether an index is a
secondary index or the insert buffer tree.

page_set_max_trx_id(), page_update_max_trx_id(),
lock_rec_insert_check_and_lock(),
lock_sec_rec_modify_check_and_lock(), btr_cur_ins_lock_and_undo(),
btr_cur_upd_lock_and_undo(): Add the parameter mtr.

page_set_max_trx_id(): Allow mtr to be NULL. When mtr==NULL, do not
attempt to write to the redo log. This only occurs when creating a
page or reorganizing a compressed page. In these cases, the
PAGE_MAX_TRX_ID will be set correctly during the application of redo
log records, even though there is no explicit log record about it.

btr_discard_only_page_on_level(): Preserve PAGE_MAX_TRX_ID. This
function should be unreachable, though.

btr_cur_pessimistic_update(): Update PAGE_MAX_TRX_ID.

Add some assertions for checking that PAGE_MAX_TRX_ID is set on all
secondary index leaf pages.

The branches/innodb+ that is mentioned in the message was supposed to be a closed-source InnoDB plugin for MySQL. In the end, all those changes were made part of MySQL 5.5.

In the code, there are some bogus references to recv_recovery_is_on() that should be removed. Also, some references could be replaced with references to index->is_dummy to prepare us for MDEV-14481 (background redo log apply).