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.

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.

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].

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

Fixes sporadic (rare) failures on buildbot

It is not reproducible, but the issue seems to be the same as with
MDEV-20490 and rocksdb.ttl_primary_read_filtering - a compaction caused
by DROP TABLE gets behind and compacts away the expired rows for the next
test. Fix this in the same way.

best_access_path() is called from two optimization phases:

1. Plan choice phase, in choose_plan(). Here, the join prefix being
   considered is in join->positions[]

2. Plan refinement stage, in fix_semijoin_strategies_for_picked_join_order
   Here, the join prefix is in join->best_positions[]

It used to access join->positions[] from stage #2. This didnt cause any
valgrind or asan failures (as join->positions[] has been written-to before)
but the effect was similar to that of reading the random data:
The join prefix we've picked (in join->best_positions) could have
nothing in common with the join prefix that was last to be considered
(in join->positions).

In mysql-server/commit@f46329044f8618212923bdf52e15d5b464201edc
the InnoDB function btr_cur_open_at_rnd_pos() was corrected so that
it would return a status that indicates whether the cursor was
successfully positioned. But this change was not correctly merged to
MariaDB in 2e814d47.

btr_cur_open_at_rnd_pos(): In the code path that was introduced in
MDEV-8588, properly return failure status.

No deterministic test case was found for this failure.
It was caught after removing the function
page_copy_rec_list_end_to_created_page() in a development branch.
As a result, the fill factor of index trees would improve, and
supposedly, so would the probability of btr_cur_open_at_rnd_pos()
reaching the intentionally corrupted page in the test
innodb.leaf_page_corrupted_during_recovery.
The wrong return value would cause
btr_estimate_number_of_different_key_vals() to wrongly invoke
btr_rec_get_externally_stored_len() on a non-leaf page and
trigger an assertion failure at the start of that function.

- During trx_undo_report_rename(), InnoDB can fail to write undo log
for it if undo log doesn't fit in the undo page. In that case, InnoDB
adds one more undo log page and retry to write the rename undo log.
But the assert is wrong and it doesn't allow to fail even for one time.

Null merge the MDEV-14383 fix; it affects 5.5 only.

there was a SELECT/DELETE race

The setting innodb_change_buffering_debug=2 was supposed to inject
a crash during change buffer merge. There is no public test for
that functionality, and even if there were, it would be better
to use DEBUG_SYNC to halt the thread that does change buffer merge,
force a redo log flush from another thread, and finally kill the
server externally.

The most likely cause of the crash is that a timer fired, after it was closed.

MSDN documents such a possibility, in the documentation for
CloseThreadpoolTimer() function, and recommends disabling the timer before
calling WaitForThreadpoolTimerCallbacks()/CloseThreadpoolTimer().

The fix follows this recommendation.

Note, that 5.5-10.1 disabled the timer before close, but this code
was lost in threadpool refactoring in 10.2

MYSQL_MAINTAINER_MODE is ERR

Remove debug output,
remove overriding of the Windows C runtime flags(linker warning)
do not add code that depends on restsdk if library is not going
to be linked.

freaking Connect

For Visual Studio generator, use a per-config .def/.lib files with symbols
exported from mysqld.exe

Functions exported from mysqld.exe may differ between debug/optimized
compilation, e.g dbug functions are missing in release config.

InnoDB intentionally (it's a documented behavior) ignores changing of
DATA DIRECTORY and INDEX DIRECTORY for partitions. Though we should
issue warning when this happens.

After SST from master node (the one where event is ENABLED) - you will end up with the event enabled on two nodes, hence it's now being executed twice. It can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED'

Changes to be committed:
	new file:   mysql-test/suite/galera/r/galera_events2.result
	new file:   mysql-test/suite/galera/t/galera_events2.test
	modified:   sql/events.cc

Test changes only.

Enable after SST script changes.

Try to use more deterministic floating-point operations.
Apparently, 2.2 > 2.2 wrongly holds on many platforms, but
not ppc64le on the compiler used on Red Had Enterprise Linux 8.
The reason could be an infinite binary presentation:
2.2 = 0b10.001100110011…

With t1_f = 2.5 = 0b10.1, t1_f > 2.5 would no longer hold on AMD64.
Let us replace the 2.2 with 2.5 and compare t1_f >= 2.5 in order to
get more consistent results across all platforms.

have the same path as in source rpms, don't build them differently

Part3: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH

Don't break compatibility in GA releases.
Warn the user, but don't refuse to create a table until 10.5

With cmake -DWITH_INNODB_AHI=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo
the variable 'i' in fseg_free_extent() was declared but not used.

The test fails because it reuses mysqltest perl code to copy directory
tree, and this code contains Windows-specific piece which outputs some
diagnostic information.

The patch introduces new parameter for that Windows-specific perl code to
have the ability to suppress diagnostic output on the corresponding
mysqltest perl module initialization.

Make the test stable: after DROP TABLE, make sure the compaction is
run and finishes.

If we don't do this, the post-drop compaction may run during the next
testcase. It will cause a record from the next testcase to be compacted
away when the test logic doesn't expect it and the test will fail

this is not ideal and needs to be fixed eventually,
but it's consistent over all forms of INSERT.

MDEV-20403 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIMESTAMP..ON UPDATE

remove a special treatment of a bare DEFAULT keyword that made it
behave inconsistently and differently from DEFAULT(column).
Now all forms of the explicit assignment of a default column value
behave identically, and all count as an explicitly assigned value
(for the purpose of ON UPDATE NOW).

followup for c7c481f4

Fix the test case.