MDEV-6789 segfault in Item_func_from_unixtime::get_date on updating table with virtual columns

* prohibit VALUES in partitioning expression
* prohibit user and system variables in virtual column expressions
* fix Item_func_date_format to cache locale (for %M/%W to return the same as MONTHNAME/DAYNAME)
* fix Item_func_from_unixtime to cache time_zone directly, not THD (and not to crash)
* added tests for other incorrectly allowed (in vcols) functions to see that they don't crash

MDEV-3940 Server crash or assertion `item->type() == Item::STRING_ITEM' failure on LOAD DATA through a view with statement binary logging

A "field" could be either an Item_field or
(if loading into a view) an Item_direct_ref that references Item_field.

Also: when iterating fields, use fields of the TABLE_LIST (table or view),
not fields of a TABLE (actual underlying table - might have more columns).

only enforce the include order if SAFE_MUTEX is defined
(that is, in MariaDB source builds in debug mode)

When parsing a field declaration, grab type information from LEX before it's overwritten
by further rules. Pass type information through the parser stack to the rule that needs it.

The test complains that the server failed to disappear upon shutdown /
wait_for_disconnect. Trying to solve the probably race condition by 
adding a wait before restart.

Excluding ORDER BY condition should be done after preparation it (even to catch syntax errors).

Backport to 5.3:
- Don't call index_reader->interrupt_read() if the
  index reader has returned all rows that matched its keys.

- Don't call index_reader->interrupt_read() if the
  index reader has returned all rows that matched its keys.

Analysis: InnoDB error monitor is responsible to call every second
sync_arr_wake_threads_if_sema_free() to wake up possible hanging 
threads if they are missed in mutex_signal_object. This is not 
possible if error monitor itself is on mutex/semaphore wait. We 
should avoid all unnecessary mutex/semaphore waits on error monitor.
Currently error monitor calls function buf_flush_stat_update() 
that calls log_get_lsn() function and there we will try to get 
log_sys mutex. Better, solution for error monitor is that in 
buf_flush_stat_update() we will try to get lsn with 
mutex_enter_nowait() and if we did not get mutex do not update 
the stats.

Fix: Use log_get_lsn_nowait() function on buf_flush_stat_update()
function. If returned lsn is 0, we do not update flush stats. 
log_get_lsn_nowait() will use mutex_enter_nowait() and if
we get mutex we return a correct lsn if not we return 0.

The test case had a classic mistake: SET DEBUG_SYNC='now SIGNAL xxx'
followed immediately by SET DEBUG_SYNC='RESET'. This makes it
possible for the waiter to miss the signal, if it does not manage
to wake up prior to the RESET.

MDEV-7089: Test failures in main.failed_auth_unixsocket and plugins.unix_socket depending on environment

The test cases had some --replace_result $USER USER. The problem is that the
value of $USER can be anything, depending on the name of the unix account that
runs the test suite. So random parts of the result can be errorneously
replaced, causing test failures.

Fix by making the replacements more specific, so they will match only the
intended stuff regardless of the value of $USER.

Merging a fix from the upstream.

Add function to print to stderr all current semaphore 
waits. This function should be able to executed 
inside a gdb/ddd.

The test runs a query in one thread, then in another queries the processlist
and expects to find the first thread in the COM_SLEEP state. The problem is
that the thread signals completion to the client before changing to COM_SLEEP
state, so there is a window where the other thread can see the wrong state.

A previous attempt to fix this was ineffective. It set a DEBUG_SYNC to handle
proper waiting, but unfortunately that DEBUG_SYNC point ended up triggering
already at the end of SET DEBUG_SYNC=xxx, so the wait was ineffective.

Fix it properly now (hopefully) by ensuring that we wait for the DEBUG_SYNC
point to trigger at the end of the SELECT SLEEP(), not just at the end of
SET DEBUG_SYNC=xxx.

(Backport to 5.3)
(Attempt #2)
- Don't attempt to use BKA for materialized derived tables. The 
  table is neither filled nor fully opened yet, so attempt to 
  call handler->multi_range_read_info() causes crash.

(Backport to 5.3)
(variant #2, with fixed coding style)
- Make Mrr_ordered_index_reader::resume_read() restore index position 
  only if it was saved before with Mrr_ordered_index_reader::interrupt_read().

- TABLE::create_key_part_by_field() should not set PART_KEY_FLAG in field->flags
  = The reason is that it is used by hash join code which calls it to create a hash
    table lookup structure. It doesn't create a real index.
  = Another caller of the function is TABLE::add_tmp_key(). Made it to set the flag itself.

- The differences in join_cache.result could also be observed before this patch: one
  could put "FLUSH TABLES" before the queries and get exactly the same difference.

Set proper alternative names on RHEL7: they should match Fedora names.

Use fn_ext2() (backported from 10.0) to get the file
extension from last occurrence of FN_EXTCHAR ('.')
instead.

Attempt to fix a failure in test case innodb.innodb_information_schema seen occasionally in Buildbot.

The test case waits for other threads to complete, but the wait is only 2
seconds. This is likely to sometimes be too little on our heavily loaded
buildbot VMs, that can easily stall for more than 2 seconds from time to time.

So let's try to increase the timeout (to about 40 seconds) and see if it
helps.

The test case runs SHOW SLAVE HOSTS. The output of this is only stable after
all slaves have had time to register with the master; this happens
asynchroneously.

The test was waiting for the slave with server_id=3 to appear in the output,
but it was missing a similar wait for server_id=2. Thus, if server_id=2 was
much slower to connect for some reason, it could be missing from the output,
causing the test to fail.