Added Atomic_counter class to replace big set of atomic operations uses
in InnoDB, as well as in the server.

The fix for MDEV-17901 did not cover cases where the AUTO_INCREMENT
column was not dropped, but some other columns before it were.

commit_cache_norebuild(): Revert the MDEV-17901 fix.

dict_index_t::clear_instant_alter(): Update table->persistent_autoinc.

innobase_instant_try(): Only try to update the hidden metadata
record if the number of columns is changing (increasing) or
a metadata BLOB is being added due to permuting or dropping columns
for the first time.

dict_table_t::instant_column(), ha_innobase_inplace_ctx::instant_column():
Return whether the metadata record needs to be updated.

MDEV-17959 Assertion `opt_bootstrap || mysql_parse_status || thd->lex->select_stack_top == 0' failed in parse_sql upon DELETE HISTORY under ORACLE mode

Ubuntu 14.04 Trusty is LTS until April 2019 and since we are
approaching that, upgrade to Xenial which is LTS until April 2021.

One bonus of this upgrade is that the Travis Xenial virtual images
have a much bigger disk size, thus no need to limit ccache below
the default of 5G anymore.

Also had to remove linux/clang-8 toolchain testing since
llvm-toolchain-xenial is not listed at:
https://github.com/travis-ci/apt-source-safelist/blob/master/ubuntu.json

And fails with:
Disallowing sources: llvm-toolchain-xenial
...
E: Unable to locate package clang-8
E: Unable to locate package llvm-8-dev

10.4 travis - newer compilers, ignore common clang warnings

MDEV-18072 Assertion `is_null() == item->null_value || conv' failed in Timestamp_or_zero_datetime_native_null::Timestamp_or_zero_datetime_native_null upon query with GROUP BY

MDEV-18070 Assertion `nanoseconds <= 1000000000' failed in Temporal::add_nanoseconds_ssff with TIME_ROUND_FRACTIONAL

The previous patch was erroneously marked as MDEV-18072.
It was actualy for MDEV-18070.

MDEV-18072 Assertion `is_null() == item->null_value || conv' failed in Timestamp_or_zero_datetime_native_null::Timestamp_or_zero_datetime_native_null upon query with GROUP BY

This assertion should have been relaxed when implementing the first part of
MDEV-15563: instant removal of NOT NULL attribute for ROW_FORMAT=REDUNDANT
tables.

For ROW_FORMAT=REDUNDANT, there is no bitmap of null columns;
the null flags are encoded in the end offset of each field.
We do not really care about the number of fields that can be NULL.

instant_alter_column_possible(): Do not allow instant removal of NOT NULL
attribute from a column that belongs to the key of the clustered index.

Ensure that the 'auxiliary transactions' that are there for
flushing the incomplete undo log of the to-be-recovered DDL
transactions are actually making modifications.

Starting with commit 6b698715
the encrypted page checksum is only computed with crc32.
Encrypted data pages that were written earlier can contain
other checksums, but new ones will only contain crc32.

Because of this, it does not make sense to implement strict
checks of innodb_checksum_algorithm for other than strict_crc32.

fil_space_verify_crypt_checksum(): Treat strict_innodb as innodb
and strict_none as none. That is, allow a match from any of the
algorithms none, innodb, crc32. (This is how it worked before the
second MDEV-12112 fix.)

Thanks to Thirunarayanan Balathandayuthapani for pointing this out.

DEV-17786: Add mariabackup test case for galera_sst_xtrabackup-v2_data_dir

fil_space_verify_crypt_checksum(): Compute the bug-compatible variant
of the CRC-32C checksum if the correct one does not match.

fil_space_verify_crypt_checksum(): Add a dummy return statement
in case memory is corrupted and innodb_checksum_algorithm has
an invalid value.

The initial fix only covered a part of Mariabackup.
This fix hardens InnoDB and XtraDB in a similar way, in order
to reduce the probability of mistaking a corrupted encrypted page
for a valid unencrypted one.

This is based on work by Thirunarayanan Balathandayuthapani.

fil_space_verify_crypt_checksum(): Assert that key_version!=0.
Let the callers guarantee that. Now that we have this assertion,
we also know that buf_page_is_zeroes() cannot hold.
Also, remove all diagnostic output and related parameters,
and let the relevant callers emit such messages.
Last but not least, validate the post-encryption checksum
according to the innodb_checksum_algorithm (only accepting
one checksum for the strict variants), and no longer
try to validate the page as if it was unencrypted.

buf_page_is_zeroes(): Move to the compilation unit of the only callers,
and declare static.

xb_fil_cur_read(), buf_page_check_corrupt(): Add a condition before
calling fil_space_verify_crypt_checksum(). This is a non-functional
change.

buf_dblwr_process(): Validate the page only as encrypted or unencrypted,
but not both.

MDEV-17848: Galera test failure on galera_sst_xtrabackup-v2[_data_dir]

A static analysis tool suggested that in the function
row_merge_read_clustered_index(), ut_free(nonnull) could
be invoked twice for nonnull!=NULL. While a manual review
of the code disproved this, it should not hurt to clean up
the code so that the static analysis tool will not complain.

index_tuple_info_t::insert(), row_mtuple_cmp(): Remove the
parameter mtr_committed, which duplicated !mtr->is_active().

row_merge_read_clustered_index(): Initialize row_heap = NULL.
Remove a duplicated call mem_heap_empty(row_heap) that was
inadvertently added in commit cb1e76e4.

Replace a "goto func_exit" with "break", to get consistent error
handling for both failures to create or write a temporary file.

end_of_index: Assign row_heap=NULL and nonnull=NULL to prevent
double freeing.

func_exit: Check for row_heap!=NULL before invoking mem_heap_free().

Closes #959

Remove provider defaults check from 'galera_defaults' MTR test

Problem is that if you use bundled yassl AES_CTR is not supported. There is a way to detect that but as we really want to keep this test enabled did not add
skip for missing support. Changed method to AES_CBC as there is no need to
use AES_CTR.

Add check that file key management plugin is found.

While calculating distinct with the function remove_dup_with_compare, we don't have rnd_end calls
when we have completed the scan over the temporary table.
Added ha_rnd_end calls when we are done with the scan of the table.

galera_prepared_statement test fixed.

connect.xml2 test result fixed.

The error message modified.
Then the TABLE_SHARE::error_table_name() implementation taken from 10.3,
          to be used as a name of the table in this message.

ported privilege checking from xtrabackup.
Now, mariabackup would terminate early if either RELOAD or PROCESS privilege
is not held, not at the very end of backup

The behavior can be disabled with nre setting --check-privileges=0.
Also , --no-lock does not need all of these privileges, since it skips
FTWRL and SHOW ENGINE STATUS INNODB.

main.partition_explicit_prune