MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t, bool): Assertion `!recv_no_log_write' failed

This is a bogus debug assertion failure that should be possible
starting with MariaDB 10.2.2 (which merged WL#7142 via MySQL 5.7.9).

While generating page-change redo log records is strictly out of the
question during tat certain parts of crash recovery, the
fil_names_clear() is only emitting informational MLOG_FILE_NAME
and MLOG_CHECKPOINT records to guarantee that if the server is killed
during or soon after the crash recovery, subsequent crash recovery
will be possible.

The metadata buffer that fil_names_clear() is flushing to the redo log
is being filled by recv_init_crash_recovery_spaces(), right before
starting to apply redo log, by invoking fil_names_dirty() on every
discovered tablespace for which there are changes to apply.

When it comes to Mariabackup (xtrabackup --prepare), it is strictly out
of the question to generate any redo log whatsoever, because that could
break the restore of incremental backups by causing LSN deviation.
So, the fil_names_dirty() call must be skipped when restoring backups.

recv_recovery_from_checkpoint_start(): Do not invoke fil_names_clear()
when restoring a backup.

mtr_t::commit_checkpoint(): Remove the failing assertion. The only
caller is fil_names_clear(), and it must be called by
recv_recovery_from_checkpoint_start() for normal server startup to be
crash-safe. The debug assertion in mtr_t::commit() will still
catch rogue redo log writes.

Let InnoDB purge reset DB_TRX_ID,DB_ROLL_PTR when the history is removed.

[TODO: It appears that the resetting is not taking place as often as
it could be. We should test that a simple INSERT should eventually
cause row_purge_reset_trx_id() to be invoked unless DROP TABLE is
invoked soon enough.]

The InnoDB clustered index record system columns DB_TRX_ID,DB_ROLL_PTR
are used by multi-versioning. After the history is no longer needed, these
columns can safely be reset to 0 and 1<<55 (to indicate a fresh insert).

When a reader sees 0 in the DB_TRX_ID column, it can instantly determine
that the record is present the read view. There is no need to acquire
the transaction system mutex to check if the transaction exists, because
writes can never be conducted by a transaction whose ID is 0.

The persistent InnoDB undo log used to be split into two parts:
insert_undo and update_undo. The insert_undo log was discarded at
transaction commit or rollback, and the update_undo log was processed
by the purge subsystem. As part of this change, we will only generate
a single undo log for new transactions, and the purge subsystem will
reset the DB_TRX_ID whenever a clustered index record is touched.
That is, all persistent undo log will be preserved at transaction commit
or rollback, to be removed by purge.

The InnoDB redo log format is changed in two ways:
We remove the redo log record type MLOG_UNDO_HDR_REUSE, and
we introduce the MLOG_ZIP_WRITE_TRX_ID record for updating the
DB_TRX_ID,DB_ROLL_PTR in a ROW_FORMAT=COMPRESSED table.

This is also changing the format of persistent InnoDB data files:
undo log and clustered index leaf page records. It will still be
possible via import and export to exchange data files with earlier
versions of MariaDB. The change to clustered index leaf page records
is simple: we allow DB_TRX_ID to be 0.

When it comes to the undo log, we must be able to upgrade from earlier
MariaDB versions after a clean shutdown (no redo log to apply).
While it would be nice to perform a slow shutdown (innodb_fast_shutdown=0)
before an upgrade, to empty the undo logs, we cannot assume that this
has been done. So, separate insert_undo log may exist for recovered
uncommitted transactions. These transactions may be automatically
rolled back, or they may be in XA PREPARE state, in which case InnoDB
will preserve the transaction until an explicit XA COMMIT or XA ROLLBACK.

Upgrade has been tested by starting up MariaDB 10.2 with
./mysql-test-run --manual-gdb innodb.read_only_recovery
and then starting up this patched server with
and without --innodb-read-only.

trx_undo_ptr_t::undo: Renamed from update_undo.

trx_undo_ptr_t::old_insert: Renamed from insert_undo.

trx_rseg_t::undo_list: Renamed from update_undo_list.

trx_rseg_t::undo_cached: Merged from update_undo_cached
and insert_undo_cached.

trx_rseg_t::old_insert_list: Renamed from insert_undo_list.

row_purge_reset_trx_id(): New function to reset the columns.
This will be called for all undo processing in purge
that does not remove the clustered index record.

trx_undo_update_rec_get_update(): Allow trx_id=0 when copying the
old DB_TRX_ID of the record to the undo log.

ReadView::changes_visible(): Allow id==0. (Return true for it.
This is what speeds up the MVCC.)

row_vers_impl_x_locked_low(), row_vers_build_for_semi_consistent_read():
Implement a fast path for DB_TRX_ID=0.

Always initialize the TRX_UNDO_PAGE_TYPE to 0. Remove undo->type.

MLOG_UNDO_HDR_REUSE: Remove. This changes the redo log format!

innobase_start_or_create_for_mysql(): Set srv_undo_sources before
starting any transactions.

The parsing of the MLOG_ZIP_WRITE_TRX_ID record was successfully
tested by running the following:
./mtr --parallel=auto --mysqld=--debug=d,ib_log innodb_zip.bug56680
grep MLOG_ZIP_WRITE_TRX_ID var/*/log/mysqld.1.err

The redo log format will be changed by MDEV-12288, and it could
be changed further during MariaDB 10.3 development. We will
allow startup from a clean redo log from any earlier InnoDB
version (up to MySQL 5.7 or MariaDB 10.3), but we will refuse
to do crash recovery from older-format redo logs.

recv_log_format_0_recover(): Remove a reference to MySQL documentation,
which may be misleading when it comes to MariaDB.

recv_log_recover_10_2(): Check if a MariaDB 10.2.2/MySQL 5.7.9
redo log is clean.

recv_find_max_checkpoint(): Invoke recv_log_recover_10_2() if the
redo log is in the MariaDB 10.2.2 or MySQL 5.7.9 format.

Even disabling the ccache on the Debian build didn't always prevent
the Travis build running out of space.

As an alternative strategy, the number of alternative compilers has been
reduced to save space. This additional space has been partially reused
by the ccache.

Debian build specific packages have been removed from other builds.

There is an inherent race condition between Mariabackup and the
MariaDB server when the InnoDB redo log is being copied. It is
possible that the tail of the circular redo log is overwriting
the head of the log before Mariabackup gets a chance to read it.
So, we reduce the test to generate less redo log. Also, enable
the test on all supported innodb_page_size.

xtrabackup_copy_log(), xtrabackup_copy_logfile():
Change the Boolean parameter to an enum, with the values
COPY_FIRST, COPY_ONLINE, COPY_LAST.

xtrabackup_copy_log(): Return the latest scanned LSN,
which may be less than the last copied LSN. Remove some
dead code that was duplicating some logic that in 10.2
has been moved to log_group_read_log_seg().

log_copying_thread(): Correct the termination condition.

stop_backup_threads(): Shut down the threads that were
created during backup.

Use GET_STR instead of GET_STR_ALLOC, so that the memory will
cannot be leaked. For some reason, calling my_cleanup_options()
on xb_server_options or xb_client_options would not work.

This reduces the probability having output of external utilities
(e.g mariabackup) truncated.

MDEV-12445 : Rocksdb does not shutdown worker threads and aborts in memleak check on server shutdown

Disable memory leak check in debug server, if rocksdb is loaded.
There is some subtle bug somewhere in 3rd party code we cannot
do much about.

The bug is manifested as follows

Rocksdb does not shutdown worker threads, when plugin is shut down. Thus
OS does not unload the library since there are some active threads using
this library's code. Thus global destructors in the library do not run,
and there is still some memory allocated when server exits.

The workaround disables server's memory leak check, if rocksdb engine was
loaded.

Use thd_query_safe() to read query from a different connection.

The option innodb_log_compressed_pages was contributed by
Facebook to MySQL 5.6. It was disabled in the 5.6.10 GA release
due to problems that were fixed in 5.6.11, which is when the
option was enabled.

The option was set to innodb_log_compressed_pages=ON by default
(disabling the feature), because safety was considered more
important than speed. The option innodb_log_compressed_pages=OFF
can *CORRUPT* ROW_FORMAT=COMPRESSED tables on crash recovery
if the zlib deflate function is behaving differently (producing
a different amount of compressed data) from how it behaved
when the redo log records were written (prior to the crash recovery).

In MDEV-6935, the default value was changed to
innodb_log_compressed_pages=OFF. This is inherently unsafe, because
there are very many different environments where MariaDB can be
running, using different zlib versions. While zlib can decompress
data just fine, there are no guarantees that different versions will
always compress the same data to the exactly same size. To avoid
problems related to zlib upgrades or version mismatch, we must
use a safe default setting.

This will reduce the write performance for users of
ROW_FORMAT=COMPRESSED tables. If you configure
innodb_log_compressed_pages=ON, please make sure that you will
always cleanly shut down InnoDB before upgrading the server
or zlib.

The dates on the these files shows they are very dated.

Following the sentiments of MDEV-9882 the default values
are quite decent so lets remove this old stuff.

The problem was that we didn't check on open of sequence if the table is a view, which is not allowed.
We are now generating a proper error message for this case.

Replace S_IREAD, S_IWRITE and S_IEXEC with more modern equivalents.
Fixes building for Android.

Since MariaDB 10.2.2, temporary table metadata is not written
to the InnoDB data dictionary tables. Therefore,
the DICT_TF2_TEMPORARY flag cannot be set in SYS_TABLES,
except if there exist orphan temporary tables that were created
before MariaDB 10.2.2.

trx_resurrect_table_locks(): Do not skip temporary tables.
If a resurrect transaction modified a temporary table that was
created before MariaDB 10.2.2, that table would be treated
internally as a persistent table. It is safer to resurrect
locks than to skip the table, because the table would be modified
on transaction rollback.

The test did not handle correctly possible difference in system
timezone. The fix is to remove non-functional setting of local
time_zone and instead allow timestamp replacement to work with
any date/time

buf_flush_page_cleaner_coordinator: In the first loop, use an
appropriate termination condition, waiting for !recv_writer_thread_active.

logs_empty_and_mark_files_at_shutdown(): Signal recv_sys->flush_start
in case the recv_writer_thread was never started, or
buf_flush_page_cleaner_coordinator failed to notice its termination.

innobase_start_or_create_for_mysql(): Remove a redundant, unreachable
condition, and properly release resources when aborting startup due to
recv_sys->found_corrupt_log.

Patch submitted by Eugene Kosov <claprix@yandex.ru>,
comments added by commiter.
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>

for compatibility with MySQL, add 'JSON' as an alias for 'TEXT'

with -DPLUGIN_PARTITION=NO and -DPLUGIN_PERFSCHEMA=NO

Fix INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT to be standard-compliant,
but keep SHOW COLUMNS backward-compatibly unchanged.

if we don't need to print field's table name,
we surely don't need to print field's db name either

Use the correct target name when querying libmariadb.so dependencies.
Filter out linker options (no-undefined and the version script)

remove double-initialization of MYSQL structure

remove ANSI_QUOTES when generating partition syntax for frm

Remove now-unused part_func_string and subpart_func_string
from partition_info.