The parameter dup_chk_only was always passed as a constant false.
Remove the parameter and the dead code related to it.

MDEV-20589: Server still crashes in Field::set_warning_truncated_wrong_value

- Use dbug_tmp_use_all_columns() to mark that all fields can be used
- Remove field->is_stat_field (not needed)
- Remove extra arguments to Field::clone() that should not be there
- Safety fix for Field::set_warning_truncated_wrong_value() to not crash
  if table is zero in production builds (We have got crashes several times
  here so better to be safe than sorry).
- Threat wrong character string warnings identical to other field
  conversion warnings. This removes some warnings we before got from
  internal conversion errors.  There is no good reason why a user would
  get an error in case of 'key_field='wrong-utf8-string' but not for
  'field=wrong-utf8-string'.  The old code could also easily give
  thousands of no-sence warnings for one single statement.

In the function test_if_cheaper_ordering we make a decision if using an index is better than
using filesort for ordering. If we chose to do range access then in test_quick_select we
should make sure that cost for table scan is set to DBL_MAX so that it is not picked.

The unit files made systemd print:

systemd[1]: Started MariaDB 10.3.13 database server (multi-instance).

Let's add the instance name, so starting mariadb@foo.service
makes it print:

systemd[1]: Started MariaDB 10.3.13 database server (multi-instance foo).

A CTE can be defined as a table values constructor. In this case the CTE is
always materialized in a temporary table.
If the definition of the CTE contains a list of the names of the CTE
columns then the query expression that uses this CTE can refer to the CTE
columns by these names. Otherwise the names of the columns are taken from
the names of the columns in the result set of the query that specifies the
CTE.
Thus if the column names of a CTE are provided in the definition the
columns of result set should be renamed. In a general case renaming of
the columns is done in the select lists of the query specifying the CTE.
If a CTE is specified by a table value constructor then there are no such
select lists and renaming is actually done for the columns of the result
of materialization.
Now if a view is specified by a query expression that uses a CTE specified
by a table value constructor saving the column names of the CTE in the
stored view definition becomes critical: without these names the query
expression is not able to refer to the columns of the CTE.

This patch saves the given column names of CTEs in stored view definitions
that use them.

mysqld_safe --dry-run needs to either call exit or return, depending if
it is being sourced or not, otherise return can lead to the error:

return: can only `return' from a function or sourced script

The original fix suggestion was proposed by FaramosCZ <mschorm@centrum.cz>

- Enable the test `sphinx.sphinx` which was disabled by MDEV 10986,
  comit ee0094d2
- Add test case to `sphinx.sphinx` to cover host as localhost instead of `127.0.0.1`
- Add result file for single test

There's an annoying bug that prevents a Sphinx table to connect to a searchd using a host name.
So the example table in the documentation https://mariadb.com/kb/en/library/about-sphinxse/#basic-usage that point's to "localhost" actually doesn't work.
After some investigation I found two errors. The first one is a wrong check after the getaddrinfo call. The second is a wrong usage of the returned struct.

Include comment header that describes overrides.

Unit description now includes @VERSION@.

After=syslog.target removed - redunant

Add --basedir=@prefix to prevent /root/.my.cnf lookups. This is
placed after $MYSQLD_OPTIONS in case a user sets a --{no,}default
type options which has to be first in the mysqld arguements.

Additional changes to multi instance (support-files/mariadb@.service.in):
* added @SYSTEMD_EXECSTARTPRE@ / @SYSTEMD_EXECSTARTPOST@
* removed mariadb@bootstrap reference as galera_new_cluster as
  it's a little too proment.
* use_galera_new_cluster.conf updated to override pre/post steps
  to ensure it has no side effects
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>

At commit, trx->lock.table_locks (which is a cache of trx_locks) can
consist of NULL pointers. Add a debug assertion for that, and clear
the vector.

The flag is_stat_field is not set for the min_value and max_value of field items
inside table share. This is a must requirement as we don't want to throw
warnings of truncation when we read values from the statistics table to the column
statistics of table share fields.

Fixes bug introduced in commit 54150029.

Using script run-time filename does not always work. One cannot assume
that the filename is always the same as there might be temporary file
names used by dpkg in certain situations. See Debian #920415.

The same fix has been successfully in use in Debian official packages
since February 2019:
https://salsa.debian.org/mariadb-team/mariadb-10.3/commit/6440c0d6e75

Problem:
=======
  During dropping of fts index, InnoDB waits for fts_optimize_remove_table()
and it holds dict_sys->mutex and dict_operaiton_lock even though the
table id is not present in the queue. But fts_optimize_thread does wait
for dict_sys->mutex to process the unrelated table id from the slot.

Solution:
========
  Whenever table is added to fts_optimize_wq, update the fts_status
of in-memory fts subsystem to TABLE_IN_QUEUE. Whenever drop index
wants to remove table from the queue, it can check the fts_status
to decide whether it should send the MSG_DELETE_TABLE to the queue.

Removed the following functions because these are all deadcode.
dict_table_wait_for_bg_threads_to_exit(),
fts_wait_for_background_thread_to_start(),fts_start_shutdown(), fts_shudown().

- There is no need to add the table in fts_optimize_wq if there is
no fts indexes associated with it.

Problem:
=======
  Transaction left with nonempty table locks list. This leads to
assumption that table_locks is not subset of trx_locks. Problem is that
lock_wait_timeout_thread() doesn't remove the table lock from
table_locks for transaction.

Solution:
========
  In lock_wait_timeout_thread(), remove the lock from table vector of
transaction.

Fix:
===
Implemented upstream fix.

commit 7d3d0fc3
Author: He Zhenxing <zhenxing.he@sun.com>

Backport Bug#45852 Semisynch: Last_IO_Error: Fatal error: Failed
to run 'after_queue_event' hook

Errors when send reply to master should never cause the IO thread
to stop, because master can fall back to async replication if it
does not get reply from slave.

The problem is fixed by deliberately ignoring the return value of
slave_reply.

Adjusted test results.

The test had been disabled in 10.2 due to frequent failures,
in 5ec9b88e.
After the problems were addressed, we failed to re-enable the test
until now.

MYSQL_PLUGIN_IMPORT did not work correctly for the RocksDB helper library
rocksdb_aux_lib, because that library was not compiled with
-DMYSQL_DYNAMIC_PLUGIN.

Fix DBUG such that it does not depend on exported data, only on functions
(which do not need MYSQL_PLUGIN_IMPORT decoration)

Use a "getter" function _db_my_assert() instead of DLL-exported variable.

Also, reduce object code duplication by moving more of the DBUG_ASSERT
logic inside the _db_my_assert() function, and add unlikely() and
ATTRIBUTE_COLD hints to ensure that the 'assertion failed' code will
be separated from the main control flow logic. Thus, the compiler can
move the unlikely() code to the end of the compiled function, reachable
via a forward conditional branch, which the processor's branch predictor
could assume 'not taken'.

Closes #739

When invoking option `--default-character-set=auto` character set
from underlying OS settings should be detected for mysqldump.

Command COM_SHUTDOWN was rejected in non-Primary because
server_command_flags[COM_SHUTDOWN] had value CF_NO_COM_MULTI
instead of CF_SKIP_WSREP_CHECK.

As a fix removed assignment
server_command_flags[CF_NO_COM_MULTI]= CF_NO_COM_MULTI
which overwrote server_command_flags[COM_SHUTDOWN].

           selectivity values fails

After having set the assertion that checks validity of selectivity values
returned by the function table_cond_selectivity() a test case from
order_by.tesst failed. The failure occurred because range optimizer could
return as an estimate of the cardinality of the ranges built for an index
a number exceeding the total number of records in the table.

The second bug is more subtle. It may happen when there are several
indexes with same prefix defined on the first joined table t accessed by
a constant ref access. In this case the range optimizer estimates the
number of accessed records of t for each usable index and these
estimates can be different. Only the first of these estimates is taken
into account when the selectivity of the ref access is calculated.
However the optimizer later can choose a different index that provides
a different estimate. The function table_condition_selectivity() could use
this estimate to discount the selectivity of the ref access. This could
lead to an selectivity value returned by this function that was greater
that 1.

On  Windows, during packaging step, if signing fails, retry
signtool again without timestamp parameter.

Fixes sporadic (rare) failures on buildbot