Fixed crash caused by x64 int/long incompatibility introduced
in Bug #29125.

Problem: Some system functions that could return different values on
master and slave were not marked unsafe. In particular:
 GET_LOCK
 IS_FREE_LOCK
 IS_USED_LOCK
 MASTER_POS_WAIT
 RELEASE_LOCK
 SLEEP
 SYSDATE
 VERSION
Fix: Mark these functions unsafe.

Fixed a problem with the test case when executed with ps-protocol.
There the conflicing lock would be noticed during prepare, not
during execution of the insert - leading to a different (but 
equally appropriate) error message.

           DELETE IGNORE

The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the
diagnostics area when it happened, but the DELETE cleanup code
never checked for a non-fatal error condition, thus trying to
set diag.area to "ok".  This triggered an assert checking that
the diag.area was empty.

The fix was to test if there existed a non-fatal error condition
(thd->is_error() before ok'ing the operation.

The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
mode active. The table being inserted into had to be different from the 
table(s) locked by LOCK TABLES.

For INSERT DELAYED, the connection thread waits until the handler thread has
opened and locked its table before returning. But since the global read lock
was active, the handler thread would be unable to lock and would wait for the
global read lock to go away.

So the handler thread would be waiting for the connection thread to release
the global read lock while the connection thread was waiting for the handler
thread to lock the table. This gave a "self-deadlock" (same connection,
different threads).

The deadlock would only happen if we also had LOCK TABLES mode since the
INSERT otherwise will try to get protection against global read lock before
starting the handler thread. It will then notice that the global read lock
is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.

This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
also if we are inside LOCK TABLES mode.

Test case added to delayed.test.

           init_read_record() - (records.cc:274)
      
Item_cond::used_tables_cache was accessed in
records.cc#init_read_record() without being initialized. It had
not been initialized because it was wrongly assumed that the
Item's variables would not be accessed, and hence
quick_fix_field() was used instead of fix_fields() to save a few
CPU cycles at creation time.

The fix is to properly initilize the Item by replacing
quick_fix_field() with fix_fields().

           deadlock was encountered

The bug is caused by an inconsistent handling of the IGNORE
clause.  A read from a const table caused a lock timeout
(ER_LOCK_TIMEOUT) in innodb.  Since the IGNORE clause was
given, the timeout was converted into a warning instead of
an error, thus not populating the diagnostics area.  When
innodb subsequently marked the transaction for rollback,
mysql asserted since the diag.area was empty.

This patch consists of only a test case, as the bug itself
was fixed by the patch for Bug #46539

       on any access

Archive engine for 5.1 (and latter) version uses a modified 
version of zlib (azlib). These two version are incompatible
so a proper upgrade is needed before tables created in 5.0 
can be used reliable.

This upgrade can be performed using repair. But due to lack 
of test its risky to allow upgrade for now. This patch addresses
only the crashing issue. Any attempt to repair will be blocked.

Eventually repair can be allowed to run through (which will also
cause an upgrade from older version to newer) but only after a 
thorough testing.

The crash occurs because SAFEMALLOC is defined for the MySQL server
but not for the Archive or Federated engines, resulting in a 
parameter mismatch between the function prototype and definition
for functions using the CALLER_INFO macro.

  memory

The server was doing a bad class typecast causing setting of 
wrong value for the maximum number of items in an internal
structure used in equality propagation.
Fixed by not doing the wrong typecast and asserting the type
of the Item where it should be done.

 values
 
 We should re-set the access method functions when changing the access
 method when switching to another index to avoid sorting.
 
 Fixed by doing a little re-engineering : encapsulating all the function
 assignment into a special function and calling it when flipping the 
 indexes.

Bug when setting up default partitioning,
used an uninitialized variabe.

When values of different types are compared they're converted to a type that
allows correct comparison. This conversion is done for each comparison and
takes some time. When a constant is being compared it's possible to cache the
value after conversion to speedup comparison. In some cases (large dataset,
complex WHERE condition with many type conversions) query might be executed
7% faster.

A test case isn't provided because all changes are internal and isn't visible
outside.

The behavior of the Item_cache is changed to cache values on the first request
of cached value rather than at the moment of storing item to be cached.
A flag named value_cached is added to the Item_cache class. It's set to TRUE
when cache holds the value of the last stored item.
Function named cache_value() is added to the Item_cache class and derived classes.
This function actually caches the value of the saved item.
Item_cache_xxx::store functions now only store item to be cached and set
value_cached flag to FALSE.
Item_cache_xxx::val_xxx functions are changed to call cache_value function
prior to returning cached value if value_cached is FALSE.
The Arg_comparator::set_cmp_func function now calls cache_converted_constant
to cache constants if they need a type conversion.
The Item_cache::get_cache function is overloaded to allow setting of the
cache type.
The cache_converted_constant function is added to the Arg_comparator class.
It checks whether a value can and should be cached and if so caches it.

            only const tables

The problem was caused by two shortcuts in the optimizer that
are inapplicable in the ROLLUP case.

Normally in a case when only const tables are involved in a
query, DISTINCT clause can be safely optimized away since there
may be only one row produced by the join. Similarly, we don't
need to create a temporary table to resolve DISTINCT/GROUP
BY/ORDER BY. Both of these are inapplicable when the WITH
ROLLUP modifier is present.

Fixed by disabling the said optimizations for the WITH ROLLUP
case.

Just change mysql_foo to mysql_cv_foo for one cache-id variable name.  There
was only one bad variable name, present in 5.0 and 5.1, but not in the -pe
branch.

The SE API requires mysql to notify the storage engine that
it's going to read certain tables at the beginning of the 
statement (by calling start_stmt(), store_lock() or
external_lock()).
These are typically called by the lock_tables(). 
However SHOW CREATE TABLE is not pre-locking the tables
because it's not expected to access the data at all.
But for some view definitions (that include comparing a
date/datetime/timestamp column to a string returning
scalar subquery) the JOIN::prepare may still access data
when materializing the scalar non-correlated subquery
in Arg_comparator::can_compare_as_dates().
Fixed by not materializing the subquery when the function
is called in a SHOW/EXPLAIN/CREATE VIEW