Removed some redundant hint related string literals from
spd_db_conn.cc

Clean up SPIDER_PARAM_*_[CHAR]LEN[S]

Adding tests covering monitoring_kind=2. What it does is that it reads
from mysql.spider_link_mon_servers with matching db_name, table_name,
link_id, and does not do anything about that...

How monitoring_* can be useful: in the deprecated spider high
availability feature, when one remote fails, spider will try another
remote, which apparently makes use of these table parameters.

A test covering the query_cache_sync table param. Some further tests
on some spider table params.

Wrapper should be case insensitive.

Code documentation on spider priority binary tree.

Add an assertion that static_key_cardinality is always -1. All tests
pass still

This helps eliminate "server exists" failures

Also, spider/bugfix.mdev_29676, when enabled after MDEV-29525 is
pushed will fail because we have not --recorded the result. But the
failure will only emerge when working on MDEV-31138 where we manually
re-enable this test, so let's worry about that then.

Spider connection string is a comma-separated parameter definitions,
where each definition is of the form "<param_title> <param_value>",
where <param_value> is quote delimited on both ends, with backslashes
acting as an escaping prefix.

Despite the simple syntax, the existing spider connection string
parser was poorly-written, complex, hard to reason and error-prone,
causing issues like the one described in MDEV-31117. For example it
treated param title the same way as param value when assigning, and
have nonsensical fields like delim_title_len and delim_title.

Thus as part of the bugfix, we clean up the spider comment connection
string parsing, including:

- Factoring out some code from the parsing function
- Simplify the struct `st_spider_param_string_parse`
- And any necessary changes caused by the above changes

don't use ps2 mode for selects with side effects

This is also related to
MDEV-31348 Assertion `last_key_entry >= end_pos' failed in virtual bool
           JOIN_CACHE_HASHED::put_record()

Valgrind exposed a problem with the join_cache for hash joins:
=25636== Conditional jump or move depends on uninitialised value(s)
==25636== at 0xA8FF4E: JOIN_CACHE_HASHED::init_hash_table()
          (sql_join_cache.cc:2901)

The reason for this was that avg_record_length contained a random value
if one had used SET optimizer_switch='optimize_join_buffer_size=off'.

This causes either 'random size' memory to be allocated (up to
join_buffer_size) which can increase memory usage or, if avg_record_length
is less than the row size, memory overwrites in thd->mem_root, which is
bad.

Fixed by setting avg_record_length in JOIN_CACHE_HASHED::init()
before it's used.

There is no test case for MDEV-31893 as valgrind of join_cache_notasan
checks that.
I added a test case for MDEV-31348.

With session tracking on the tx_isolation of importance to
connector frameworks, its important that tracking of tx_isolation
does get informed if a user `set session transaction_isolation=X`
as the alias for tx_isolation.

Rather than just implement this for one variable alias, it
is implemented for all aliases.

To assist with this the key hash of session_tracker is now made up of
the offset, not the sys_var pointer.

The impacts of aliases are:
- If track one variable, its alias changes, you get a tracking
  change on the variable you are monitoring.
- If you track two aliased variables of each other, changing
  a variable will have a tracking events for only one of them.

Aliases of Sys_var_bit are not implemented, because we don't
have them, so would've been no way to verify that the new code works.

Post-Review edits by Sergei Golubchik <serg@mariadb.com>

# Conflicts:
#	mysql-test/main/sp.result
#	mysql-test/main/sp.test

The reason is that --bootstrap is used to initialize the server and
a lot of processes are not started in this case. Event scheduler is
not an exception.

This fix also removes an unexpected warning about event scheduler when
running mariadb_install_db.

Remove redundant delete_explain_query() calls in

sp_instr_set::exec_core(), sp_instr_set_row_field::exec_core(),
sp_instr_set_row_field_by_name::exec_core().

These calls are made before the SP instruction's tables are
"closed" by close_thread_tables() call.

When we call close_thread_tables() after that, we no longer
can collect engine's counter variables, as they use the data
structures that are located in the Explain Data Structures.

Also, these delete_explain_query() calls are redundant, as
sp_lex_keeper::reset_lex_and_exec_core() has another
delete_explain_query() call, which is located in the right
location after the close_thread_tables() call.

- InnoDB aborts when table is dropping the column. This is
caused by 5f09b53b (MDEV-31086).
While iterating the altered table fields, we fail to consider
the dropped columns.