The function Item_direct_view_ref::fix_fields erroneously did not correct
the value of the flag maybe_null when the view for which the item was
being fixed happened to be an inner table of an outer join.
 

The function SELECT_LEX::update_used_tables first must clean up
all bitmaps to be recalculated for all tables that require it
and only after this walk through on conditions attached to the
tables to update these bitmaps.
  

- when create_ref_for_key() is constructing a ref access for
  a table that's inside a SJ-Materialization nest, it may not 
  use references to fields of tables that are unside the nest (because 
  these fields will not yet have values when ref access will be used)
  
  The check was performed in the first of create_ref_for_key's loops (the 
  one which counts how many key parts are usable) but not in the second
  (the one which actually fills the TABLE_REF structure). 

If a materialized derived table / view is empty then for this table
the value of file->ref is 0. This was not taken into account by
the function JOIN_CACHE::write_record_data. As a result a query
using an empty materialized derived tables as inner tables of outer
joins and IN subqueries in WHERE conditions could cause server crashes
when the optimizer employed join caches and duplicate elimination for
semi-joins.

Do not create KEYUSEs for a materialized view over a constant table. 

This bug happened because the function Item_cond::eval_not_null_tables
erroneously did not initialize the value of not_null_tables_cache.

The method DsMrr_impl::dsmrr_init erroneously tried to get a KEY descriptor
for key with number MAX_KEY. This caused valgrind complains.

This bug happened for the queries over multi-table mergeable views
because the bitmap TABLE::read_set of the underlying tables were not
updated after the views had been merged into the query.
Now this bitmaps are updated properly.
Also the bitmap TABLE::merge_keys now is updated in prevention of
future bugs.

The function JOIN::drop_unused_derived_keys could erroneously set
the value of REF::key to 0 for a joined materialized view/derived table
in the case when no REF access to the table was used by the query
execution plan. This could cause a crash of the server.

This bug happened due to incompleteness of the fix for bug 872735:
the occurrences of the fields in the conditions of correlated
subqueries were not taken into account when recalculating
covering keys bit maps.

This bug manifested itself with queries containing non-correlated
IN subqueries over materialized views/derived tables.  
The bug happened because the code of the function generate_derived_keys did
not take into account that the function could be called twice when the
optimizer was deciding whether in-exist transformation should be applied.

Print server version name to .err file on crash 

scripts/make_binary_distribution.sh:
  Remove extra MariaDB- from binary tar.gz file name
sql/mysqld.cc:
  Print server version name to .err file on crash (to ensure people paste also that when they report a crash)

Fixed wrong parameter type for --general-log. Now one can enable it with --general-log= 1 | true | on
Fixed that bool parameters can also take 'on' and 'off' as parameters. This is in line with the values assigned to them in mysqld.


mysys/my_getopt.c:
  Fixed that bool parameters can also take 'on' and 'off' as parameters.
sql/mysqld.cc:
  Fixed wrong info message for mysqld --general-log
  Fixed wrong parameter type for --general-log. Now one can enable it with --general-log= 1 | true | on

This bug happened because the maps of covering keys for mergeable derived
tables/views was not recalculated after the derived tables/vies had been
merged into the main query.

restore the status quo from before the microsecond patch

- Testcase