Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

mysql-test/r/timezone3.result:
  Bug #39920: test case
mysql-test/std_data/Moscow_leap:
  Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i 
  to accomodate for the 2008 leap second
mysql-test/t/timezone3.test:
  Bug #39920: test case
sql/tztime.cc:
  Bug #39920: adjust leap seconds (:60 or :61) to :59
sql/tztime.h:
  Bug #39920: adjust leap seconds (:60 or :61) to :59

by using and taking out a full path.

mysql-test/r/ctype_filesystem.result:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37399: use MYSQL_TEST_DIR rooted test
mysql-test/t/ctype_filesystem.test:
  Bug #37399: use MYSQL_TEST_DIR rooted test

TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().

Diff to actual 5.0-bugteam is revno: 2725 only

            leads to an assertion failure

Any run-time error in stored function (like recursive function
call or update of table that is already updating by statement
which invoked this stored function etc.) that was used in some
expression of the single-table UPDATE statement caused an
assertion failure.
Multiple-table UPDATE (as well as INSERT and both single- and
multiple-table DELETE) are not affected.


mysql-test/r/update.result:
  Added test case for bug #40745.
mysql-test/t/update.test:
  Added test case for bug #40745.
sql/sql_update.cc:
  Bug #40745: Error during WHERE clause calculation in UPDATE
              leads to an assertion failure
  
  The mysql_update function has been updated to take into account
  the status of invoked stored functions before setting the status
  of whole UPDATE query to OK.

            an error

Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:

1. "SELECT FROM regular table USE/FORCE/IGNORE(non
   existent index)" fails with a "ERROR 1176 (HY000):
   Key '...' doesn't exist in table '...'"

2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
   with a "ERROR 1221 (HY000): Incorrect usage of
   USE/IGNORE INDEX and VIEW".  OTOH "SHOW INDEX FROM
   view" always returns empty result set, so from the point
   of same behaviour view we trying to use/ignore non
   existent index.

To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.


mysql-test/r/view.result:
  Added test case for bug #33461.
  Updated test case for bug 28701.
mysql-test/t/view.test:
  Added test case for bug #33461.
  Updated test case for bug 28701.
sql/sql_view.cc:
  Bug #33461: SELECT ... FROM <view> USE INDEX (...) throws
              an error
  
  To harmonize the behaviour of USE/FORCE/IGNORE(index)
  clauses in SELECT from a view and from a regular table the
  "ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
  and VIEW" message has been replaced with the "ERROR 1176
  (HY000): Key '...' doesn't exist in table '...'" message
  like for tables and non existent keys.

      
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave 
variables and use it when processing data.

mysql-test/r/ctype_filesystem.result:
  Bug #37339: test case (should be in utf-8)
mysql-test/t/ctype_filesystem-master.opt:
  Bug #37339: test case (should be in ISO-8859-1)
mysql-test/t/ctype_filesystem.test:
  Bug #37339: test case
sql/mysqld.cc:
  Bug #37339: remember the correct character set for init_slave and init_connect
sql/set_var.cc:
  Bug #37339: 
    - remember the character set of the relevant variables
    - implement storing and using the correct 
      character set
sql/set_var.h:
  Bug #37339: implement storing and using the correct 
  character set
sql/sql_show.cc:
  Bug #37339: implement storing and using the correct 
  character set

.bzrignore:
  Added autom4te.cache and language directories in sql/share to ignorefile.

sql/slave.cc:
  compiler warning fix

mysql-test/r/perror-win.result:
  pushbuild failure fix
mysql-test/t/perror-win.test:
  pushbuild failure fix
sql/item_func.cc:
  pushbuild failure fix

No commit message

The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win,
If MySQL is compiled with valgrind there are errors about
using of uninitialized variable(orig_table).
The fix is to set field->orig_table correct value.


mysql-test/r/innodb_mysql.result:
  test result
mysql-test/t/innodb_mysql.test:
  test case
sql/sql_base.cc:
  set field->orig_table to 'table' value because it may be bogus and
  it leads to crash on Field_string::type() function.

Reason for the failing test was that "SELECT count(*) from mysql.general_log;" was not always
the same number. That was fixed by "...count(*)>4..." as the minimal fulfilled condition.
As Bug 35371 was fixed the testcase with "log_output = 'FILE'" was enabled and changed to have
always the same result.

enable uncacheable flag if we update a view with check option
and check option has a subselect, otherwise, the check option
can be evaluated after the subselect was freed as independent
(See full_local in JOIN::join_free())


mysql-test/r/subselect.result:
  test result
mysql-test/t/subselect.test:
  test case
sql/mysql_priv.h:
  added UNCACHEABLE_CHECKOPTION flag
sql/sql_update.cc:
  enable uncacheable flag if we update a view with check option
  and check option has a subselect, otherwise, the check option
  can be evaluated after the subselect was freed as independent
  (See full_local in JOIN::join_free())