Modified according to the review comment

The loop in the binary search in remove_status_vars() was
incorrectly implemented and could continue infinitely in some cases.
Rewrote the binary search code.

An addition to fix for MDEV-5205, fixes server crash on shutdown.

Thread groups are destroyed asynchronously, that is kill server
thread sends shutdown request to all thread groups without waiting
for compeltion.

It means all_groups array must not be freed until all thread groups
are down. This patch suggests that all_groups is freed when last
thread group is destroyed.

Note 1: threadpool code doesn't surround atomic ops with atomic locks,
thus no locks for shutdown_group_count.
Note 2: this patch preserves old behaviour, but we may need to wait
until all thread groups are down before returning from tp_end().

include/CMakeLists.txt:
  Added handler_ername.h
include/handler_ername.h:
  Names of handler error messages
mysql-test/extra/binlog_tests/binlog.test:
  Test using handler error names
mysql-test/r/mysqltest.result:
  Update for new error message
mysql-test/t/auto_increment.test:
  Test using handler error names
mysql-test/t/auto_increment_ranges.inc:
  Test using handler error names
mysql-test/t/replace.test:
  Test using handler error names

storage/xtradb/handler/ha_innodb.cc:
  Fixed wrong last argument to buf_LRU_free_block(): The LRU chain is already locked by this function.

- thread_pool_size command line option upper limit increased to 100 000
  (same as for max_connections)
- thread_pool_size system variable upper limit is maximum of 128 or
  the value given at command line
- thread groups are now allocated dynamically

Different limit for command line option and system variable was done to
avoid additional mutex for all_groups and threadpool_max_size.

  
  There was 2 problems:
  1) coping/moving of the same type (usually casting) as sizeof() (solved in different ways depends on the cause);
  2) using 'const' in SSL_CTX::getVerifyCallback() which return object (not reference) and so copy of the object will be created and 'const' has no sens.

Analysis:
st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
As a result join->prepare() gets called with order == NULL, and
doesn't do name resolution for the inner ORDER clause. Due to this
the prepare phase doesn't detect that the query references non-exiting
function and field.
  
Later join->optimize() calls update_used_tables() for a non-resolved
Item_field, which understandably has no Field object. This call results
in a crash.

Solution:
Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
objects. Then remove such clauses from the JOIN object.

- Backport MySQL's fix: do set ha_partition::m_pkey_is_clustered for ha_partition 
  objects created with handler->clone() call.
- Also, include a testcase.

test time increased to be working on all timezones.

Slackware install docs to different folder, which wasn't handled
by file_contents test properly. E.g. on Redhat/Debian docs are
expected to be in /usr/share/doc/mariadb-server-(version), but
on Slackware they are in /usr/doc/mariadb-(version).

For details see Slackware mariadb build script:
http://slackbuilds.org/slackbuilds/14.0/system/mariadb/mariadb.SlackBuild

MDEV-5143: update of a joined table with a nested subquery with a syntax error crashes mysqld with signal 11

Added check of SELECT_LEX::handle_derived() result.

fix for SP & PS

MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery

Make reset null_row same as it was set in evaluate_null_complemented_join_record().

The problem was that view firlds detect null_row by not-yet-reset table.

The patch for bug mdev-5105 incorrectly counted conditions in nested joins.

Objects of the classes Item_func_isnull and Item_func_isnotnull
must have the flag sargable set to TRUE.
Set the value of the flag sargable only in constructors of the 
classes inherited from Item_int_func.

The bug caused a memory overwrite in the function update_ref_and_keys()
It happened due to a wrong value of SELECT_LEX::cond_count. This value
historically was calculated by the fix_fields method. Now the logic of
calling this method became too complicated and, as a result, this value
is calculated not always correctly.
The patch changes the way how and when  the values of SELECT_LEX::cond_count
and of SELECT_LEX::between_count are calculated. The new code does it just at
the beginning of update_ref_and_keys().
 

For aggregated fields from views/derived tables the possible adjustment
of thd->lex->in_sum_func->max_arg_level in the function Item_field::fix_fields
must be done before we leave the function.

Added collection statistics for queries resolved via query cache.