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.

This should be a non-functional change. I was unable to repeat
MDEV-11626 innodb.innodb-change-buffer-recovery fails for xtradb
and cannot determine the reason for the failure without having access
to the files.

The repeatability of MDEV-11626 should not be affected by these changes.

MDEV-11317: `! is_set()' or `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' fails in Diagnostics_area::set_ok_status on CREATE OR REPLACE with ARCHIVE table

Problem was with deleting non existing .frm file for a storage engine that
doesn't have .frm files (yet)

Fixed by not giving an error for non existing .frm files for storage engines
that are using discovery
Fixed also valgrind supression related to the given test case

Change the parameter type from ulong to uint, so that 32-bit and
64-bit systems will report an identical result.