MySQL 5.7 allows temporary tables to be created in ROW_FORMAT=COMPRESSED.
The usefulness of this is questionable. WL#7899 in MySQL 8.0.0
prevents the creation of such compressed tables, so that all InnoDB
temporary tables will be located inside the predefined
InnoDB temporary tablespace.

Pick up and adjust some tests from MySQL 5.7 and 8.0.

dict_tf_to_fsp_flags(): Remove the parameter is_temp.
fsp_flags_init(): Remove the parameter is_temporary.

row_mysql_drop_temp_tables(): Remove. There cannot be any temporary
tables in InnoDB. (This never removed #sql* tables in the datadir
which were created by DDL.)

dict_table_t::dir_path_of_temp_table: Remove.

create_table_info_t::m_temp_path: Remove.

create_table_info_t::create_options_are_invalid(): Do not allow
ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE for temporary tables.

create_table_info_t::innobase_table_flags(): Do not unnecessarily
prevent CREATE TEMPORARY TABLE with SPATIAL INDEX.
(MySQL 5.7 does allow this.)

fil_space_belongs_in_lru(): The only FIL_TYPE_TEMPORARY tablespace
is never subjected to closing least-recently-used files.

MySQL 5.7 introduced partial support for user-created shared tablespaces
(for example, import and export are not supported).

MariaDB Server does not support tablespaces at this point of time.
Let us remove most InnoDB code and data structures that is related
to shared tablespaces.

The MariaDB 10.1 page_compression is incompatible with the Oracle
implementation that was introduced in MySQL 5.7 later.

Remove the Oracle implementation. Also remove the remaining traces of
MYSQL_ENCRYPTION.

This will also remove traces of PUNCH_HOLE until it is implemented
better. The only effective call to os_file_punch_hole() was in
fil_node_create_low() to test if the operation is supported for the file.

In other words, it looks like page_compression is not working in
MariaDB 10.2, because no code equivalent to the 10.1 os_file_trim()
is enabled.

MariaDB will likely never support MySQL-style encryption for
InnoDB, because we cannot link with the Oracle encryption plugin.
This is preparation for merging MDEV-11623.

Added testcase

The INFORMATION_SCHEMA view INNODB_TEMP_TABLE_INFO was added to
MySQL 5.7 as part of the work to implement temporary tables
without any redo logging.

The only use case of this view was SELECT COUNT(*) in some tests,
to see how many temporary tables exist in InnoDB. The columns do
not report much useful information. For example, the table name
would not be the user-specified table name, but a generated #sql
name. Also, the session that created the table is not identified.

Test crash recovery from an encrypted redo log with innodb_encrypt_log=0.
Previously, we did a clean shutdown, so only the log checkpoint
information would have been read from the redo log. With this change,
we will be reading and applying encrypted redo log records.

include/start_mysqld.inc: Observe $restart_parameters.

encryption.innodb-log-encrypt: Remove some unnecessary statements,
and instead of restarting the server and concurrently accessing
the files while the server is running, kill the server, check the
files, and finally start up the server.

innodb.log_data_file_size: Use start_mysqld.inc with $restart_parameters.

The symbol HAVE_VALGRIND_MEMCHECK_H was never defined.
Instead, the symbol HAVE_VALGRIND should have been used.

- Changed error handlers interface so that they can change error level in
  the handler
- Give warnings and errors when calculating virtual columns
- On insert/update error is fatal in strict mode.
- SELECT and DELETE will only give a warning if a virtual field generates an error
- Added VCOL_UPDATE_FOR_DELETE and VCOL_UPDATE_INDEX_FOR_REPLACE to be able to
  easily detect in update_virtual_fields() if we should use an error
  handler to mask errors or not.

Problem was that one internal record buffer in MYISAM was not big enough to handle virtual fields.
Fixed by extending buffer.

Fixed test case to 79 characters

Issue was that the m_prebuilt array was reused without resetting a counter,
which caused a memory overrun.

Adjusted test case to 79 characters

MDEV-11598 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed

Found and fixed 2 problems:

- Filesort addon fields didn't mark virtual columns properly
- multi-range-read calculated vcol bitmap but was not using it.
  This caused wrong vcol field to be calculated on read, which caused the assert.

- rpl_gtid_stop_start:  Random failure
- sysvars_innodb,32bit: Fixes for 32 bit

* Ensure that BUILD scripts cleans up things properly before new BUILD
* MySQL -> MariaDB
* Ignore wrong valgrind memleak

Needed as GNUTLS can't be used by MariaDB on many systems,
like OpenSuse 13.2

When updating a table with virtual BLOB columns, the following might
happen:
- an old record is read from the table, it has no virtual blob values
- update_virtual_fields() is run, vcol blob gets its value into the
  record. But only a pointer to the value is in the table->record[0],
  the value is in Field_blob::value String (but it doesn't have to be!
  it can be in the record, if the column is just a copy of another
  columns: ... b VARCHAR, c BLOB AS (b) ...)
- store_record(table,record[1]), old record now is in record[1]
- fill_record() prepares new values in record[0], vcol blob is updated,
  new value replaces the old one in the Field_blob::value
- now both record[1] and record[0] have a pointer that points to the
  *new* vcol blob value. Or record[1] has a pointer to nowhere if
   Field_blob::value had to realloc.

To fix this I have introduced a new String object 'read_value' in
Field_blob.  When updating virtual columns when a row has been read,
the allocated value is stored in 'read_value' instead of 'value'.  The
allocated blobs for the new row is stored in 'value' as before.

I also made, as a safety precaution, the insert delayed handling of
blobs more general by using value to store strings instead of the
record.  This ensures that virtual functions on delayed insert should
work in as in the case of normal insert.

Triggers are now properly updating the read, write and vcol maps for used
fields. This means that we don't need VCOL_UPDATE_FOR_READ_WRITE anymore
and there is no need for any other special handling of triggers in
update_virtual_fields().

To be able to test how many times virtual fields are invoked, I also
relaxed rules that one can use local (@) variables in DEFAULT and non
persistent virtual field expressions.

This reverts commit f73bdb68.

- MDEV-11621 rpl.rpl_gtid_stop_start fails sporadically in buildbot
- MDEV-11620 rpl.rpl_upgrade_master_info fails sporadically in buildbot

The issue above was probably that the build machine was overworked and the
shutdown took longer than 30 resp 10 seconds, which caused MyISAM tables
to be marked as crashed.
Fixed by flushing myisam tables before doing a forced shutdown/kill.
I also increased timeout for forced shutdown from 10 seconds to 60 seconds
to fix other possible issues on slow machines.

Fixed also some compiler warnings

- privilege_table_io.test didn't properly reset roles_mapping
- Fixed memory allocation problem with CHECK CONSTRAINT, found when
  running --valgrind main.check_constraint

- Atomic writes are enabled by default
- Automatically detect if device supports atomic write and use it if
  atomic writes are enabled
- Remove ATOMIC WRITE options from CREATE TABLE
  - Atomic write is a device option, not a table options as the table may
    crash if the media changes
- Add support for SHANNON SSD cards

- Not documented on intened usage
- Extra checking takes time for all HASH usage

This is done without using any additional memory
Added internal test case

This is similar to MDEV-7716

buf_flush_init_flush_rbt() was called too early in MariaDB server 10.0,
10.1, MySQL 5.5 and MySQL 5.6. The memory leak has been fixed in
the XtraDB storage engine and in MySQL 5.7.

As a result, when the server is started to initialize new data files,
the buf_pool->flush_rbt will be created unnecessarily and then leaked.
This memory leak was noticed in MariaDB server 10.1 when running the
test encryption.innodb_first_page.

        Have to use 'keyname' to check the name uniqueness.

Perform a slow shutdown at the start of the test, and create all
InnoDB tables with STATS_PERSISTENT=0, so that any I/O related to
background tasks (change buffer merge, purge, persistent statistics)
should be eliminated.