Fixing the bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Null merging the changes from 5.5 related to bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Null merging the changes from 5.5 related to bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Fixing the bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Null merging the changes from 5.6 for bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Fixing the bug 16919882 - WRONG FSF ADDRESS IN LICENSES HEADERS
Manual merge BUG#14615536 MySQL 5.6 -> trunk
Bug#16872677 DO NOT IGNORE THE RETURN VALUE OF FWRITE() IN INNOCHECKSUM

a) Handle the return value of fwrite(), fgetpos() and fsetpos().
b) Created new function write_file() to update the checksum values
   for --write option for innochecksum tool.

Approved by Kevin. rb#2526
WL#6739 semi-join: Move LooseScan out of best_access_path()
* Class Loose_scan_opt is removed
* its functionality is moved into a new function
* semijoin_loosescan_fill_driving_table_position().
* Instead of calling several member functions of the above class in
* best_access_path (), we make best_access_path () store three numbers
in the Key_use object
* and after best_access_path () we call
semijoin_loosescan_fill_driving_table_position() which uses to these
three numbers.
* A first benefit is that in the absence of semi-join,
best_access_path () executes less code.
* A second benefit is that if there is a semi-join, debugging is made
easier (the developer only needs to follow one call to
semijoin_loosescan_fill_driving_table_position()).
* Other improvements done in this patch:
** ref access is now possible in semi-join LooseScan (it never worked
in 5.6 and was thus disabled), see certain plan changes in result
files
** in semi-join LooseScan, the discovery of bound equalities does not
depend anymore on the existence of an index on the inner side of the
equality; instead, multiple equalities are searched for references
to available-in-join-prefix expressions. We thus discover more bound
equalities.
** Tests are added. New and modified code is covered at 100%.
Null-merge 5.6 -> trunk
merge from 5.6
Merge from mysql-5.6 to mysql-trunk
Fix Bug#16369955 MYSQL_INSTALL_DB EXITS WITH "UNKNOWN/UNSUPPORTED STORAGE
ENGINE: INNODB"

Do not try to create mysql.innodb_table_stats and mysql.innodb_index_stats
during mysql_install_db time if InnoDB is not present (not compiled in).
MERGE : mysql-trunk --> mysql-trunk-wl5766
WL#5766 : PERFORMANCE SCHEMA, stored programs instrumentation.

Details:
 - 3rd round of review comments from Marc.
Bug#14615536: OPTIMIZER TRACE PRINTS RANGES FOR 
              NON-APPLICABLE KEYPARTS

Before, the "ranges [...]" part of optimizer trace would include
ranges for keyparts that were not usable by range access. Two
such cases have been found:

WHERE keypart1 < const AND keypart2 ... 
(or any other non-equality operator for keypart1)
  => keypart2 is not applicable for range access because
     the operator on keypart1 is not equality, but optimizer
     tracing would print the range for keypart2 anyway

WHERE keypart1 = const AND keypart3 ...
  => keypart3 is not applicable for range access because
     there are no predicates for keypart2, but optimizer
     tracing would print the range for keypart3 anyway

Both issues are fixed by this CS.
BUG#14615536 Followup. 

opt_range.cc:append_range_all_keyparts() is now needed in 
non-debug builds, so the function must be compiled in
unconditionally.
Fix for
Bug#16739050 PREPARED STATEMENT: CRASH IN ITEM_REF::REAL_ITEM OR PURE
VIRTUAL FUNCTION CALL
and 2 duplicates:
don't reach to real items when creating prep_having. Details:

First, let's review some bugs fixed in older 5.6 versions.
==========================================================

About the fix for 12603457 and 12603141:
WHERE condition is "WHERE field".
JOIN::conds is made, by change_item_tree(), to point to item_outer_ref
which points to item_field.
At fix_prepare_information() we do:
  prep_where= JOIN::conds
When we rollback_item_tree_changes(), we restore conds, which does not
modify prep_where (only JOIN::conds was registered in the "list of
changes to roll back"...).
When next execution starts reinit_stmt_before_use() copies prep_where
into select_lex->where, which thus gets the now-destroyed
item_outer_ref, later this crashes.
Solution which was chosen: make reinit_stmt_before_use() copy
prep_where->real_item(), to reach to the field, avoiding the
now-destroyed item_outer_ref.
For uniformity, the same was done for prep_having.

About the fix for 12582849: (cousin of above)
WHERE condition is OR.
One argument of OR is made to point to item_outer_ref which points to
item_field.
At JOIN:: optimize:
  prep_where= copy of conds => makes a copy of OR (a new item_cond_or).
When we rollback_item_tree_changes(), we restore one pointer argument
of the original OR, which does not modify the pointer argument of the
copy of this OR (do not modify prep_where); the now-destroyed
item_outer_ref remains in prep_where. Then it crashes at next
execution.
Solution which was chosen: make the copy code (copy_andor_structure)
use real_item().

About the fix for Bug #16163596:
regression caused by the fix for 12603457 and 12603141.
In sql_yacc, "HAVING a" leads to the creation of an Item_ref named
"a". In having->fix_fields(), we find that "a" is actually a field, so
we make the Item_ref's ref point to this field.
At next execution, reinit_stmt_before_use()  uses real_item() which
makes the HAVING be item_field, not Item_ref anymore. This Item_ref
should have staid, it's a permanent, parse-time item.
There should never be Item_field in HAVING, see how sql_yacc creates
Item_ref instead of Item_field if in HAVING.
Removing this item_ref confused ROLLUP.
Solution which was chosen: undo the HAVING part of the fix for
12603457 and 12603141.

Now the new bugs.
=================

16317817:
HAVING condition is OR.
We resolve GROUP BY:
- initially order->item points to order->item_ptr which contains (per
parser) Item_field.
- in find_order_in_list(), *order_item (i.e. order->item_ptr) is made
to point to item_outer_ref, this change done in fix_fields() goes
through register_item_tree_change().
- again in find_order_in_list(), we append this item to
ref_pointer_array, and make order->item point to this new cell of the
array.
One argument of OR in HAVING is item_ref (per parser).
We resolve HAVING: this argument of OR is made to reference
order->item (id est: the ref_pointer_array cell which references the
item of GROUP BY). Keep in mind that Item_ref is Item**, not Item*.
Then we rollback_item_tree_changes(), which effectively restores
order->item_ptr.
reinit_stmt_before_use() restores order -> item to point to order ->
item_ptr. So GROUP BY is fine.
But the item_ref in HAVING still references the cell of
ref_pointer_array which was not restored.
reinit_stmt_before_use()  makes a copy of HAVING, which uses
copy_andor_structure, which reaches to the real items
(per the fix for 12582849), but as HAVING is "item_ref to destroyed
item_outer_ref to item_field", this crashes.
If it would not reach to the real item, the copy would stop at the
item_ref, then the soon-coming name resolution would create a new
item_outer_ref and point the item_ref to it, all fine.

16739050: similar to above

16317685:
HAVING condition is OR.
In HAVING, one Item_ref is made to reference COUNT;
reinit_stmt_before_use(),  using copy_andor_structure() which uses
real_item(), changes HAVING to COUNT, then ROLLUP crashes.

PROPOSED SOLUTION
=================

Avoid using real_item() in copy_andor_structure() when copying HAVING,
because it's only causing problems.
Keep real_item() when copying WHERE, in 5.6. We cannot remove it,
because of the "second copy" done in JOIN::optimize():
    sel->prep_where=
conds ? conds->copy_andor_structure(thd, true) : NULL;
which creates new AND/OR items which "argument pointers" will not be properly restored
(re-read 12582849 above), thus forcing us to reach to the real items.
In WL#7082 (5.7), the second copy will go away, so real_item() can be
removed (done in my prototype).
Bug#16314835 "WITH ROLLUP" CAUSES: DUPLICATE ENTRY 'NULL' FOR KEY '<AUTO_KEY>'
Bad result in 5.1/5.5, strange error in 5.6
=> disable ROLLUP+DISTINCT, with meaningful error.
DISTINCT is often useless with GROUP BY anyway.
Of the modified testcases, most are for internally-reported bugs.
ROLLUP+ORDER is already disabled.