- Properly define build dependencies via addons/homebrew, but still keep
  secondary Homebrew run until OS X builds fully work.
- Remove references to OS X bugs that are already closed.
- As long as the OS X build does not work, it is enough to attempt to run
  just one of them, no need for many in parallel. It will just waste
  resources and slow down the job from finishing quickly.

This further simplifies and cleans up the Travis-CI file without making
any major functional changes.

With this structure .travis.yml is much easier to read and thanks to the
added documentation next developers are less likely to mess it up again
as they can more easily see how the jobs matrix work.

Number of jobs:
- before: 33 (with 7 ignored)
- after:  33 (with 7 ignored)

This partially reverts commits c12609dd and 193bc89a.

Remove unnecessary dependencies that nothing uses: dpatch libzmq-dev

Install extra build dependencies from a PPA specifically tailored for
Travis-CI use and which ensures all architectures are supported (in this
case s390x is needed and was not available from mariadb.org repos).

Validated with https://config.travis-ci.com/explore

This is first step in refactoring the Travis-CI file, which had become a
mess. This commit has no functional changes, just syntactical cleanup
and simplification.

Dependencies list has not changes, it is just sorted alphabetically so
it is easier to compare to e.g. debian/control file list.

innodb_init_params(): make sure that srv_n_log_files == 1 always

MDEV-22012 Allow SET TIMESTAMP for users with GRANT BINLOG REPLAY when --secure-timestamp=replication

when selecting from perfschema, filter out statements
used by the test istself in wait_condition.inc, because they,
by design, can be repeated unpredictable number of times.

btr_blob_free(): Compare page_id_t directly.

buf_pool_watch_unset(): Avoid unnecessarily buf_pool.mutex acquisition.

Clean up some comments as well.

Remove unnecessary buf_pool_t:: qualifiers. In comments,
replace buf_pool::mutex with buf_pool.mutex.

Remove an outdated comment about a planned buffer pool resizing feature.
It is already implemented in MariaDB 10.2.2 (and MySQL 5.7.9).

- mbmaxlen is always 0 for binary field. Ignore the assert of checking
field->prefix_len % field->col->mbmaxlen == 0.

fix manpages in Debian

To change all executables to have a mariadb name I had to:
- Do name changes in every CMakeLists.txt that produces executables
- CREATE_MARIADB_SYMLINK was removed and GET_SYMLINK added by Wlad to reuse the function in other places also
- The scripts/CMakeLists.txt could make use of GET_SYMLINK instead of introducing redundant code, but I thought I'll leave that for next release
- A lot of changes to debian/.install and debian/.links files due to swapping of real executable and symlink. I did not however change the name of the manpages, so the real name is still mysql there and mariadb are symlinks.
- The Windows part needed a change now when we made the executables mariadb -named. MSI (and ZIP) do not support symlinks and to not break backward compatibility we had to include mysql named binaries also. Done by Wlad

my_atomic.h is included indirectly anyways.

The code that commit bb24fa31
moved to a separate file assume_aligned.h was introduced in
commit 25e2a556 and developed
by employees of MariaDB Corporation.

* Remove dead code

* MDEV-21675 Data inconsistency after multirow insert rollback

This patch fixes data inconsistencies that happen after rollback of
multirow inserts, with binlog disabled.
For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')`
that fail with duplicate key error. In such cases the whole statement
is rolled back. However, with wsrep_emulate_binlog in effect, the
IO_CACHE would not be truncated, and the pending rows events would be
replicated to the rest of the cluster. In the above example, it would
result in row (1,'a') being replicated, whereas locally the statement
is rolled back entirely. Making the cluster inconsistent.
The patch changes the code so that prior to statement rollback,
pending rows event are removed and the stmt cache reset.
That patch also introduces MTR tests that excercise multirow insert
statements for regular, and streaming replication.

Also, clean up the test innodb_gis.geometry a little further.

Remove CREATE/DROP database.

Remove some unnecessary suppressions, replacements, and
SQL statements.

Populate tables via have_sequence.inc to avoid the creation of
explicit InnoDB record locks in INSERT...SELECT. This will remove
some gaps in AUTO_INCREMENT values.

After MDEV-12353, the consistency check that I originally added for
commit 1b9fe0bb
(InnoDB Plugin for MySQL 5.1) started randomly failing.

It turns out that the IMPORT TABLESPACE code was always incorrect:
it did not update the (redundantly stored) tablespace ID
in index tree root pages. It only does that for page headers
and BLOB pointers.

PageConverter::update_index_page(): Update the tablespace ID
in the BTR_SEG_TOP and BTR_SEG_LEAF of index root pages.

Forcing wait on nodes 2 and 3, to turn wsrep_ready to 'ON' before querying wsrep status variables.
This guarantees that status reads don't come too early on these nodes

The problem happened in these line:

uval0= (ulonglong) (val0_negative ? -val0 : val0);
uval1= (ulonglong) (val1_negative ? -val1 : val1);

return check_integer_overflow(val0_negative ? -(longlong) res : res,
                              !val0_negative);

when unary minus was performed on -9223372036854775808.
This behavior is undefined in C/C++.

After MDEV-12353, the consistency check that I originally added for
commit 1b9fe0bb
(InnoDB Plugin for MySQL 5.1) started randomly failing.

It turns out that the IMPORT TABLESPACE code was always incorrect:
it did not update the (redundantly stored) tablespace ID
in index tree root pages. It only does that for page headers
and BLOB pointers.

PageConverter::update_index_page(): Update the tablespace ID
in the BTR_SEG_TOP and BTR_SEG_LEAF of index root pages.

A large INSERT would occasionally fail with a deadlock error. This
is due to a limitation in galera library: large writesets that are
internally fragmented (> 32KB), may fail to replicate during a
configuration change. Even if the configuration change is from primary
to primary.
Changed the test to reduce writeset sizes from ~65K to ~16K.

Several macros such as sint2korr() and uint4korr() are using the
arithmetic + operator while a bitwise or operator would suffice.

GCC 5 and clang 5 and later can detect patterns consisting of
bitwise or and shifts by multiples of 8 bits, such as those used
in the InnoDB function mach_read_from_4(). They actually translate
that verbose low-level code into high-level machine language
(i486 bswap instruction or fused into the Haswell movbe instruction).

We should do the same for MariaDB Server code that is outside InnoDB.

Note: The Microsoft C compiler is lacking this optimization.
There, we might consider using _byteswap_ushort(), _byteswap_ulong(),
_byteswap_uint64(). But, those would lead to unaligned reads, which are
bad for reasons stated in MDEV-20277. Besides, outside InnoDB,
most data is already being stored in the native little-endian format
of that compiler.