TVC can be used in IN subquery and in PARTITION BY struct now.
Special variable to control working of optimization added.

Trasformation goes that way:
a in (1,2) ->
a in (select * from (values ((1),(2))) as new_tvc)

Special variable that controlls optimization added.
Now optimization works only in several cases.
New tests added.

Old tests corrected. Now with TVC explain can be used. TVC also can be used in recursive CTEs.

TVCs can be used separately, with UNION/UNION ALL, in derived tables,
in views and in common table expressions.

Tests corrected.
Test results added.

TVC can be used in UNION-statement, in view and in subquery.

Files where TVC is defined and its methods are stored added.
Methods exec and prepare for TVC added.
Tests for TVC added.

CLOCKS_PER_SEC not used anymore.
start_timer()/mysql_end_timer() don't make much sense.
Buffer size requirement increased by 1 byte.

As svoj points out, my_timer_microseconds uses gettimeofday which is
affected by "discontinuous jumps in the system time", according to
man.

This patch changes to use microsecond_interval_timer which is "not
perfect, but is less affected by these jumps", and also does not
require an include of my_rdtsc.h header.

https://github.com/MariaDB/server/pull/332#discussion_r114708923

"No space before "=" and space after cast please"
https://github.com/MariaDB/server/pull/332#discussion_r114708923

Oversight spotted by svoj:
https://github.com/MariaDB/server/pull/332#discussion_r114708923

based upon: https://github.com/dveeden/mysql-server/commit/d5e46428075d86dbdc333d27951bb06cb4c11a32

MariaDB [test]> select sleep(0.123);
+--------------+
| sleep(0.123) |
+--------------+
|            0 |
+--------------+
1 row in set (0.123 sec)

"More exact timing for mysql client based on my_timer_microseconds"

Based on suggestion from @grooverdan on https://github.com/mysql/mysql-server/pull/112

This patch is slightly bigger because the original did not preserve the
return type of my_timer_microseconds and this patch does.
   (my_timer_microseconds returns ulonglong, not simply ulong)

Also I believe the correct place to do the division of microseconds to
seconds is better in the caller of nice_time because nice_time takes a
"double sec" param, so we should convert before calling; the other caller
of nice_time does not call with microseconds.

The following options will be removed:

innodb_file_format
innodb_file_format_check
innodb_file_format_max
innodb_large_prefix

They have been deprecated in MySQL 5.7.7 (and MariaDB 10.2.2) in WL#7703.

The file_format column in two INFORMATION_SCHEMA tables will be removed:

innodb_sys_tablespaces
innodb_sys_tables

Code to update the file format tag at the end of page 0:5
(TRX_SYS_PAGE in the InnoDB system tablespace) will be removed.
When initializing a new database, the bytes will remain 0.

All references to the Barracuda file format will be removed.
Some references to the Antelope file format (meaning
ROW_FORMAT=REDUNDANT or ROW_FORMAT=COMPACT) will remain.

This basically ports WL#7704 from MySQL 8.0.0 to MariaDB 10.3.1:

commit 4a69dc2a95995501ed92d59a1de74414a38540c6
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Wed Mar 11 22:19:49 2015 +0200

This excludes MDEV-12472 (InnoDB should accept XtraDB parameters,
warning that they are ignored). In other words, MariaDB 10.3 will not
recognize any XtraDB-specific parameters.

Fixed the following things from the above MDEV:
- Ensure the user has INSERT privilege when generating new sequence values
  with NEXT VALUE FOR or SETVAL()
- Fixed bug in InnoDB when generating several sequence values in one statement
- Ensure that read_set is up to date before calling ha_sequence::ha_write_row()
  - This is only a potential bug with storage engines that trusts the column maps completely

This is needed for MyISAM and other storage engines which normally
relies on THR_LOCK's to ensure that one is not writing the same block
one could be reading from.

The fix for MDEV-12866 fixed this problem as well. Adding tests only.

Recent changes in Type_handler fixed this problem. Adding tests only.

Adding tests for MDEV-9408 CREATE TABLE SELECT MAX(int_column) creates different columns for table vs view

Recent fixes in Type_handler fixed this problem. Adding tests only.

Adding tests for MDEV-9406 CREATE TABLE..SELECT creates different columns for IFNULL() and equivalent COALESCE,CASE,IF

Recent changes in Type_handler fixed this problem as well.
Adding tests only.

Previous fixes in Type_handler
(see the patch for MDEV-12875, MDEV-12886, MDEV-12916)
fixed this problem as well. Adding only the test from the report.

Fixing to pass item->name.str rather than item->name to my_error().

row_search_mvcc(): Relax debug assertions. For NO_ROLLBACK tables,
a transaction or a read view will not be started at the start of
a statement.

row_upd_clust_step(): Support CREATE TEMPORARY SEQUENCE or
CREATE TEMPORARY TABLE…NO_ROLLBACK.

A cleanup for MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems

Removing cmp_item::get_comparator() and calling instead
Type_handler::make_cmp_item(), which was earlier introduced by this patch:

74891ed2

This is a joint patch fixing the following problems:

MDEV-12875 Wrong VIEW column data type for COALESCE(int_column)
MDEV-12886 Different default for INT and BIGINT column in a VIEW for a SELECT with ROLLUP
MDEV-12916 Wrong column data type for an INT field of a cursor-anchored ROW variable

All above problem happened because the global function ::create_tmp_field()
called the top-level Item::create_tmp_field(), which made some tranformation
for INT-result data types. For example, INT(11) became BIGINT(11), because 11
is a corner case and it's not known if it fits or does not fit into INT range,
so Item::create_tmp_field() converted it to BIGINT(11) for safety.

The main idea of this patch is to avoid such tranformations.

1. Fixing Item::create_tmp_field() not to have a special case for INT_RESULT.

   Item::create_tmp_field() is changed not to have a special case
   for INT_RESULT (which earlier made a decision based on Item's max_length).
   It now calls tmp_table_field_from_field_type() for INT_RESULT,
   therefore preserves the original data type (e.g. INT, YEAR) without
   conversion to BIGINT.

   This change is valid, because a number of recent fixes
   (e.g. in Item_func_int, Item_hybrid_func, Item_int, Item_splocal)
   guarantee that item->type_handler() now properly returns
   type_handler_long vs type_handler_longlong. So no adjustment by length
   is needed any more for Items returning INT_RESULT.

   After this change, Item::create_tmp_field() calls
   tmp_table_field_from_field_type() for all XXX_RESULT, except REAL_RESULT.

2. Fixing Item::create_tmp_field() not to have a special case for REAL_RESULT.

   Note, the reason for a special case for REAL_RESULT is to have a special
   constructor for Field_double(), forcing Field_real::not_fixed to be set
   to true.

   Taking into account that only Item_sum descendants actually need a special
   constructor call Field_double(not_fixed=true), not too loose precision
   when mixing individual rows to the aggregate result:
   - renaming Item::create_tmp_field() to Item_sum::create_tmp_field().
   - changing Item::create_tmp_field() just to call
     tmp_table_field_from_field_type() for all XXX_RESULT types.

   A special case for REAL_RESULT in Item::create_tmp_field() is now gone.
   Item::create_tmp_field() is now symmetric for all XXX_RESULT types,
   and now just calls tmp_table_field_from_field_type().

3. Fixing Item_func::create_field_for_create_select() not to have
   a special case for STRING_RESULT.

   After changes #1 and #2, the code in
   Item_func::create_field_for_create_select(), testing result_type(),
   becomes useless, because: now Item::create_tmp_field() and
   tmp_table_field_from_field_type() do exactly the same thing for all
   XXX_RESULT types for Item_func descendants:
   a. It calls tmp_table_field_from_field_type for STRING_RESULT directly.
   b. For other XXX_RESULT, it goes through Item::create_tmp_field(),
      which calls the global function ::create_tmp_field(),
      which calls item->create_tmp_field() for FUNC_ITEM,
      which calls tmp_table_field_from_field_type() again.

   So removing the virtual implementation of
   Item_func::create_field_for_create_select().
   The inherited Item::create_field_for_create_select() now perfectly
   does the job, as it also calls tmp_table_field_from_field_type()
   for FUNC_ITEM, independently from XXX_RESULT type.

4. Taking into account #1 and #2, as well as some recent changes,
   removing virtual implementations:
   - Item_hybrid_func::create_tmp_field()
   - Item_hybrid_func::create_field_for_create_select()
   - Item_int_func::create_tmp_field()
   - Item_int_func::create_field_for_create_select()
   - Item_temporal_func::create_field_for_create_select()
   The derived versions from Item now perfectly work.

5. Moving a piece of code from create_tmp_field_from_item()
   to a new function create_tmp_field_from_item_finalize(),
   to reuse it in two places (see #6).

6. Changing the code responsible for BIT->INT/BIGIN tranformation
   (which is called for the cases when the created table, e.g. HEAP,
    does not fully support BIT) not to call create_tmp_field_from_item(),
   because the latter now calls tmp_table_field_from_field_type() instead
   of create_tmp_field() and thefore cannot do BIT transformation.
   So rewriting this code using a sequence of these calls:
   - item->type_handler_long_or_longlong()
   - handler->make_and_init_table_field()
   - create_tmp_field_from_item_finalize()

7. Miscelaneous changes:
   - Moving type_handler_long_or_longlong() from "protected" to "public",
     as it's now needed in the global function create_tmp_field().

8. The above changes fixed MDEV-12875, MDEV-12886, MDEV-12916.
   So adding tests for these bugs.

The fix for MDEV-12876 fixed this problem as well.
So adding tests only.

- Test with LOCK TABLES
- Test mysqldump
- Don't update rows for sequence tables if values doesn't change. This is
  needed as InnoDB gives an error for updates where values doesn't change.