Apply the contributed patch from
MySQL Bug #89126 create table panic on innobase_parse_hint_from_comment
by Yan Huang.

xb_assign_undo_space_start(): Correctly pass the length of
the buffer, so that the file name will not be truncated.

dict_load_table_low(): When flagging an error, assign *table = NULL.
Failure to do so could cause a crash if an error was flagged when
accessing INFORMATION_SCHEMA.INNODB_SYS_TABLES.

MDEV-15948 Fix error "Lost connection to MySQL server..." in test gal…

While the test case crashes a MariaDB 10.2 debug build only,
let us apply the fix to the earliest applicable MariaDB series (10.0)
to avoid any data corruption on a table-rebuilding ALTER TABLE
using ALGORITHM=INPLACE.

innobase_create_key_defs(): Use altered_table->s->primary_key
when a new primary key is being created.

* Increased timeout counter in galera_wait_ready.inc

* Replaced useless include/wait_until_ready.inc after start_mysqld.inc
  in galera_st_*.inc with wait_condition on cluster size.

MDEV-15374 Server hangs and aborts with long semaphore wait or assertion `len < ((ulint) srv_page_size)' fails in trx_undo_rec_copy upon ROLLBACK on temporary table

Problem:
=======
InnoDB cleans all temporary undo logs during commit. During rollback
of secondary index entry, InnoDB tries to build the previous version
of clustered index. It leads to access of freed undo page during
previous transaction commit and it leads to undo log corruption.

Solution:
=========
During rollback, temporary undo logs should not try to build
the previous version of the record.

MDEV-15929 Fix lock wait timeout on `SELECT @@GLOBAL.WSREP_ON`

followup for a3c980b3

same change in Locked_tables_list::unlink_from_list(), otherwise
thd->locked_tables_list will keep pointers to a free'd TABLE if
prelocked under lock tables.

This fixes a crash in main.create_or_replace on debug Win builds
after bcb36ee2

do_stmt_close() is embedded-aware.

this fixes the failure of innodb.innodb_bug48024 --ps --embed

Test galera_sst_mysqldump often fails with error "2013: Lost connection
to MySQL server during query". The connection is lost after the test
restart one of the nodes. This happens because the server closes client
connections if it is joining a cluster through SST method mysqldump.
On unlucky runs of the test it is possible that mysqld is restarted,
and then mtr client is disconnected while it tries to determine if
galera is ready before going on with the test.
This patch rewrites galera_wait_ready.inc so that it is immune to
being disconnected.

MDEV-15456 Server crashes upon adding or dropping a partition in ALTER under LOCK TABLE after ER_SAME_NAME_PARTITION

ALTER TABLE ... ADD PARTITION modifies the open TABLE structure,
and sets table->need_reopen=1 to reset these modifications
in case of an error.

But under LOCK TABLES the table isn't get reopened, despite need_reopen.

Fixed by reopening need_reopen tables under LOCK TABLE.

bad merge

in a specially crafted invalid packet, one can get end_pos < pos here

disable online alter add primary key for innodb, if the
table is opened/locked more than once in the current connection

(see assert in ha_innobase::add_index())

test case

MyRocks internally will print non-critical messages to
sql_print_verbose_info() which will do what InnoDB does in similar cases:
check if (global_system_variables.log_warnings > 2).

slave node killed himself.

Problem:- If we try to delete table with foreign key and table whom it is
referring with wsrep_slave_threads>1 then galera tries to execute both
Delete_rows_log-event in parallel, which should not happen.

Solution:- This is happening because we do not have foreign key info in
write set. Upto version 10.2.7 it used to work fine. Actually it happening
because of issue in commit 2f342c45. wsrep_must_process_fk has changed to
make it similar to original condition.

This patch fixes a lock wait timeout error on `SELECT @@GLOBAL.WSREP_ON`
in `wait_wsrep_ready.inc`:

```
--connection node_2
...
--source include/kill_galera.inc

--connection node_1
--source include/wait_until_connected_again.inc # This includes wait_wsrep_ready.inc

```

The problem is that on node_2, kill_galera.inc may return before
the node is killed. So node_1 may still see that node_1 is alive
and will attempt to sync wait when doing those `SELECT` statements.
But sync wait is doomed to fail given that node_1 is killed, hence
the lock wait timeout.
One possible fix is to disable wsrep_sync_wait before including
wait_until_connected_again.
However, it appears that including wait_until_connected_again is
not necessary at all in node_1, so this patch removes it altogether.

- If select query chooses the index 'b' over clustered index then the issue
can happen. Changed the test case to use primary index for the select
query.

- During rollback, redo segments priorities over no-redo rollback
segments and it leads to failure of redo rollback segment undo
logs truncation.

Usage of aggregate/window functions in non-recursive parts of recursive CTEs
is allowed. Error messages complaining about this were reported by mistake.

one cannot do keyread on spatial indexes.

Any expensive WHERE condition for a table-less query with
implicit aggregation was lost. As a result the used aggregate
functions were calculated over a non-empty set of rows even
in the case when the condition was false.

This bug manifested itself when the optimizer chose an execution plan with
an access of the recursive CTE in a recursive query by key and ARIA/MYISAM
temporary tables were used to store recursive tables.
The problem appeared due to passing an incorrect parameter to the call of
instantiate_tmp_table() in the function With_element::instantiate_tmp_tables().

The cause of this bug was the same as for the bug mdev-15575.
Fixed by the patch for the latter.

This bug happened due to a defect of the implementation of the handler
function ha_delete_all_rows() for the ARIA engine.
The function maria_delete_all_rows() truncated the table, but it didn't
touch the write cache, so the cache's write offset was not reset.
In the scenario like in the function st_select_lex_unit::exec_recursive
when first all records were deleted from the table and then several new
records were added some metadata became inconsistent with the state of
the cache. As a result the table scan function could not read records
at the end of the table.
The same defect could be found in the implementation of ha_delete_all_rows()
for the MYISAM engine mi_delete_all_rows().

Additionally made late instantiation for the temporary table used to store
rows that were used for each new iteration when executing a recursive CTE.

revert incorrect change