MDEV-16792 Assertion `m_status == DA_ERROR' failed in Diagnostics_area::sql_errno or wrong result upon SHOW TABLE STATUS after adding partition under ANSI_QUOTES

if opening a table fails with a syntax error, the error shouldn't
be suppressed completely as if it didn't happen at all.

RPM solution:

Make all server plugins to restart the server when installed.
To avoid multiple server restarts, do it only once in posttrans scriptlet.
Add support for CPACK_RPM_<component>_POST_TRANS_SCRIPT_FILE

Make different threads that are running data_copy_thread_func()
use the same pthread_mutex for locking (not the copies of the same
pthread_mutex_t).

Simplify, and make it work with system tablespace outside of
innodb data home.

Also, do not reread TRX_SYS page  in endless loop,
if it appears to be corrupted.

Use finite number of attempts.

		if custom undo tablespace is defined

- In case of multiple undo tablespace, mariabackup have to open system
tablespace to find the list of undo tablespace present in TRX_SYS page.
For opening system tablespace, mariabackup should fetch the file name
from already initialized system tablespace object.

Test changes only.

Added forgotten code signing command.

The function st_select_lex_unit::exec_recursive() missed resetting of
select_limit_cnt and offset_limit_cnt before execution of union parts.
As a result recursive CTEs specified by UNIONs whose SELECTs contained
LIMIT/OFFSET could return wrong sets of records.

This amends commit 4dc20ff6.

Starting with MariaDB 10.2, InnoDB defines
typedef size_t ulint;

The standard format for size_t uses the z modifier, for example,
"%zu" as in the macro ULINTPF.

"%lu" is wrong for size_t, because sizeof(unsigned long) can be
something else than sizeof(size_t). On Windows, the former would
always be 4 bytes, while size_t would be 4 or 8 bytes.

In MySQL 5.7, a follow-up to WL#6671 removed the unused
fields ha_innobase::lock and INNOBASE_SHARE::lock, but
MariaDB did not remove them, even though a counterpart of
WL#6671 itself was implemented as MDEV-7660 in
commit d665e79c.

INNOBASE_SHARE was removed in MDEV-16557. Thus, all that
needs to be removed is the unused member ha_innobase::lock
and related code.

Thanks to Monty (and Valgrind) for noticing that
ha_innobase::lock was uninitialized.

The problem was that the original alias was replaced with a new allocated
string, but constraint item's are still pointing to the original alias.

Fixed by storing the original alias used when printing constraint in the
tables mem_root.

Structures based on Gcalc_dyn_list need to be treated
properly when copied in Item::get_copy().

This patch fills a serious flaw in the implementation of common table
expressions. Before this patch an attempt to prepare a statement from
a query with a parameter marker in a CTE that was used more than once
in the query ended up with a bogus error message. Similarly if a statement
in a stored procedure contained a CTE whose specification used a
local variables and this CTE was referred to more than once in the
statement then the server failed to execute the stored procedure returning
a bogus error message on a non-existing field.

The problems appeared due to incorrect handling of parameter markers /
local variables in CTEs that were referred more than once.

This patch fixes the problems by differentiating between the original
occurrences of a parameter marker / local variable used in the
specification of a CTE and the corresponding occurrences used
in copies of this specification. These copies are substituted
instead of non-first references to the CTE.

The idea of the fix and even some code were taken from the MySQL
implementation of the common table expressions.

Add new target win_package, that produces
a) light ZIP (no test suite, no sql-bench, no debugsymbols)
b) debug symbols ZIP

The problem occurs in 10.2 and earlier releases of MariaDB Server because the
Partition Engine was not pushing the engine conditions to the underlying
storage engine of each partition.  This caused Spider to return the first 5
rows in the table with the data provided by the customer.  2 of the 5 rows
did not qualify the WHERE clause, so they were removed from the result set by
the server.

To fix the problem, I have back-ported support for engine condition pushdown
in the Partition Engine from MariaDB Server 10.3.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

Merged:
  Commit eb2ca3d4 on branch bb-10.2-MDEV-16912

When counter increment is not within the expected range, print the number
instead of just FAIL.

This doesnt solve the bug but will help with the diagnostics.

Don't add the comma if nothing appended to the array.

Item_func_json_search needs a member to store the path.

The problem occurs in 10.2 and earlier releases of MariaDB Server because the
Partition Engine was not pushing the engine conditions to the underlying
storage engine of each partition.  This caused Spider to return the first 5
rows in the table with the data provided by the customer.  2 of the 5 rows
did not qualify the WHERE clause, so they were removed from the result set by
the server.

To fix the problem, I have back-ported support for engine condition pushdown
in the Partition Engine from MariaDB Server 10.3.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

MariaDB does not support changed page tracking, since 10.2. Remove bitmap
initialization

Extra comma added to the result when an json array is empty.

There was change in error reporting from my_error to my_message so new recording is required.

This assertion fails in thread that removes all table instances for
particular table from table cache (e.g. "DROP TABLE") while another
thread evicts table instance of the same table from table cache
concurrently.

After "MDEV-10296 - Multi-instance table cache" there is a gap in
eviction code of tc_add_table() between removing table from free_tables
and all_tables not protected by any mutexes.

This is now valid table cache state, however assertion wasn't amended
along with original patch. Moved assertion down, after waiting for such
table instances to get closed.

This problem manifested itself when a join query used two or more
materialized CTE such that each of them employed the same recursive CTE.
The bug caused a crash. The crash happened because the cleanup()
function was performed premature for recursive CTE. This clean up was
induced by the cleanup of the first CTE referenced the recusrsive CTE.
This cleanup destroyed the structures that would allow to read from the
temporary table containing the rows of the recursive CTE and an attempt to read
these rows for the second CTE referencing the recursive CTE triggered a
crash.
The clean up for a recursive CTE R should be performed after the cleanup
of the last materialized CTE that uses R.

recv_addr_state, recv_addr_t: Define in log0recv.cc only.