Range analysis of non-indexed columns should handle properly range trees
with type == SEL_TREE::MAYBE.

Valgrind complained on usage of uninitialized memory.

The values of the column HIST_TYPE from the statistical table
mysql.column_stats were stored in the table and read from the
table incorrectly.

Avoid possible division by 0.

Don't try to a histogram if it is not read into the cache for statistical data.
It may happen so if optimizer_use_condition_selectivity is set to 3. This 
setting orders the optimizer not use histograms to calculate selectivity.

When performing the range analysis for a conjunction the function
calculate_cond_selectivity_for_table should take in to account that
the analysis of some conjuncts may return SEL_ARG::IMPOSSIBLE.

When calculating selectivity of conditions one should take into account
the cases when some tables to be joined are empty.

Wrong formulas used by the function Histogram::point_selectivity()
could result in a negative value of selectivity returned by the
function.

Range analysis of the condition for a non-indexed column may
return an impossible range. This must be taken into account.

mysqltest: At line 477: query 'show explain for $thr2' failed: 1933: Target is not running an EXPLAINable command

After the fix for MDEV-4144, subquery with WHERE pk= (select ...) became a degenerate, constant 
SELECT.  It is not executed in normal way anymore, so it is not possible to catch it in-execution.

The bug was caused a wrong casting.

It popped up because the latest fix to handle properly null
ranges was not complete.

calculating selectivity of conditions.

Introduced double precision height-balanced histograms.

One of them is quite serious: the function table_cond_selectivity used
the TABLE_REF structure for ref/eq_ref access methods as if they had been
filled. In  fact these structure are filled after the best execution plan
has been chosen.

The other bugs happened due to:
- an erroneous attempt at get statistics on the result of materialization
  of a view
- incorrect handling of ranges with no left/right limits when calculating
  selectivity of range conditions on non-indexed columns
- lack of cleanup for some newly introduced fields
 

  
Analysis:
The reason for the inefficent plan was that Item_subselect::is_expensive()
didn't detect the special case when a subquery was optimized, but had no
join plan because it either has no table, or its tables have been optimized
away, or the optimizer detected that the result set is empty.
  
Solution:
Identify the special cases above in the Item_subselect::is_expensive(),
and consider such degenerate subqueries inexpensive.

This bug was introduced by the patch for WL#3220.
If the memory allocated for the tree to store unique elements
to be counted is not big enough to include all of them then
an external file is used to store the elements.
The unique elements are guaranteed not to be nulls. So, when 
reading them from the file we don't have to care about the null
flags of the read values. However, we should remove the flag 
at the very beginning of the process. If we don't do it and
if the last value written into the record buffer for the field
whose distinct values needs to be counted happens to be null,
then all values read from the file  are considered to be nulls
and are not counted in.
The fix does not remove a possible null flag for the read values.
Rather it just counts the values in the same way it was done
before WL #3220.

Extend plugin auth api to support up to 512 bytes in the user names.
Use the API versioning to support old auth plugins too!

          The get_mbr() method shouldn't return the error, rather an invalid MBR
          in this case.

Fixed printing column_get finction.

-Wno-invalid-offsetoff  is a C++ warnng, not C.

Patch by Pavel Ivanov.