update test results for embedded

followup for 564a63b5 and 89a87e8e

Discrepancy in open indexes due to overwritten `read_partitions` upon
`ha_open()` in `ha_partition::clone()`.

[Fixes tempesta-tech/mariadb#551]

The semisync ack collector hits fd's out-of-bound value assert through
a stack of

/usr/sbin/mysqld(_ZN12Ack_receiver17get_slave_socketsEP6fd_setPj+0x70)[0x7fa3bbe27400]

/usr/sbin/mysqld(_ZN12Ack_receiver3runEv+0x540)[0x7fa3bbe27980]

/usr/sbin/mysqld(ack_receive_handler+0x19)[0x7fa3bbe27a79]

The reason of the failure must be the same as in https://bugs.mysql.com/bug.php?id=79865
whose fixes are applied with minor changes.

Specifically, the semisync ack thread is changed to use poll()
instead of select() on platforms where the former is defined.
On the systems that still use select(), Ack receive thread will generate
an error and semi sync will be switched off. Windows systems is exception
case because on windows this limitation does not exists.

The sustain manual testing with `mysqlslap --concurrency > 1024' in "background" while the slave io thread is restarting multiple times.

MDEV-17693 Shift/reduce conflicts for NAMES,ROLE,PASSWORD in the option_value_no_option_type grammar

MDEV-17660 sql_mode=ORACLE: Some keywords do not work as label names: history, system, versioning, without
MDEV-17661 Add sql_mode specific tokens for the keyword DECODE

Use exit instead of return.

Changing the way how a cursor is opened to fetch its structure only,
e.g. for a cursor FOR loop record variable.

The old methods with setting thd->lex->limit_rows_examined to an Item_uint(0)
was not reliable and could push these messages into diagnostics area:

  The query examined at least 1 rows, which exceeds LIMIT ROWS EXAMINED (0)

The new method should be more reliable, as it completely prevents the call
of do_select() in JOIN::exec_inner() during the cursor structure discovery,
so the execution of the cursor SELECT query returns immediately after the
preparation step (when the result row structure becomes known),
without even entering the code that fetches the result rows.

The following merges changed sql_yacc.yy but not sql_yacc_ora.yy:
commit 862af4d2
commit df563e0c

Apply the same fixes to the other parser.

This bug in the code of the function With_element::check_unrestricted_recursive()
could force a recursive CTE to be executed in a non-standard compliant mode
in which recursive UNION ALL could lead to an infinite execution. This
problem could occur only in the case when this CTE was used by another
recursive CTE at least twice.

There was a failure in rpl_delayed_slave after recent MDEV-14528 commit.
The parallel applier should not set its
Relay_log::last_master_timestamp from Format-descriptor log event.
The latter may reflect a deep past so Seconds-behind-master will be
computed through it and displayed all time while the first possibly
"slow" group of events is executed.

The main MDEV-14528 is refined, rpl_delayed_slave now passes also
in the parallel mode.

Remove the separate test innodb.alter_instant, because
it can be easily mistaken for innodb.instant_alter, which
in turn is covering various instant ALTER TABLE operations.

Fix is not to use blocking socket IO during SSL handshake.
With non-blocking socket IO, threadpool is able to utilize the wait
notification callbacks, that vio_io_wait() is calling whenever
socket would block.

When replicated events are from Master unaware of MariaDB GTID their handling by
the Parallel slave misses Seconds_Behind_Master updating.

In the bug condition the Show-Slave-Status' field remains unchanged.

Because in such case event execution is sequential the bug
is fixed with deploying the same logics as in the explicit single-threaded mode
with is to set

  Relay_log_event::last_master_timestamp

member early at the end of event reading from the relay log.

It tests SQL-level feature that is available in FB/MySQL and not in MariaDB

add a test case

ping is not a reliable way to detect github's availability

Background: Used encryption key_id is stored to encryption metadata
i.e. crypt_data that is stored on page 0 of the tablespace of the
table. crypt_data is created only if implicit encryption/not encryption
is requested i.e. ENCRYPTED=[YES|NO] table option is used
fil_create_new_single_table_tablespace on fil0fil.cc.

Later if encryption is enabled all tables that use default encryption
mode (i.e. no encryption table option is set) are encrypted with
default encryption key_id that is 1. See fil_crypt_start_encrypting_space on
fil0crypt.cc.

ha_innobase::check_table_options()
	If default encryption is used and encryption is disabled, you may
        not use nondefault encryption_key_id as it is not stored anywhere.