adjust/modify tests as they were failing if system time zone is set differently.

bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently.

because the search pattern for the "INFO_*" files was not general enough:
Fixed.

       
Sun Studio 12 has an error when calculating the compile-time 
length of a constant character string.  The error is only 
present when building an optimized 32-bits version, using 
the -xbuiltin=(%all) compiler flag. 
       
During compilation, the compiler recognizes the use of 
the strlen() function used on a constant string. It 
optimizes the strlen and replaces it with the actual 
length of the string.   This optimization seems to 
calculate the length wrongly in this particular case. 
       
Replacing the "const char *" with a "const char []" 
solves the problem. 

but the latter only takes one argument, duh!
Fixed by concatenating the args (replace , with .)

  This is a redo for 5.5
  Added 'innodb_file_format_max' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server

Problematic query:
insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
When this query is killed in another connection it could lead to crash.
The problem is follwing:
An attempt to obtain table statistics for subselect table in killed query
fails with an error. So JOIN::optimize() for subquery is failed but
it does not prevent further subquery evaluation.
At the first subquery execution JOIN::optimize() is called
(see subselect_single_select_engine::exec()) and fails with
an error. 'executed' flag is set to TRUE and it prevents
further subquery evaluation. At the second call
JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
and in case of uncacheable subquery the 'executed' flag is set
to FALSE before subquery evaluation. So we loose 'optimize stage'
error indication (see subselect_single_select_engine::exec()).
In other words 'executed' flag is used for two purposes, for
error indication at JOIN::optimize() stage and for an
indication of subquery execution. And it seems it's wrong
as the flag could be reset.

rw_lock_x_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_SHARED).

rw_lock_s_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_EX).

Bug 12980094 - ASSERTION IN INNODB DETECTED IN RQG_PARTITION_DDL
Bug 13034534 - RQG TESTS FAIL ON WINDOWS WITH CRASH NEAR RW_LOCK_DEBUG_PRINT

All access to struct rw_lock_debug_struct must be protected by rw_lock_debug_mutex_enter().

Upmerge from 5.1 to 5.5

Change the RPM spec file so that each RPM "obsoletes" the corresponding RPMs
of all (other) configurations, so a "server" RPM of any configuration
can replace the "server" RPM of any other configuration on a "rpm -U".

Fix for commit_1innodb failure on pb2.

Background: as status increment differs for an unsafe statement 
when logged in stmt and row format,  mtr throws a content mismatch
error.

Fix:  call p_verify_status_increment with different arguments
for loging format as stmt and row/mixed and disable query log.  

                      COMPILE ON MACOSX LION

The problem was that on optimized builds, the wrong code was generated
for my_atomic_add64 if a variable argument was optimized away as a
constant.

This patch fixes the problem by making the variable volatile.

Another workaround is to specify architecture explicitly using e.g.
CFLAGS/CXXFLAGS= "-m64".

No test case added.

  run_query_stmt() might use disable_xxx vars after calling handle_no_error
  But handle_no_error() hes reverted any ONCE settings
  Fix is to take revert_properties() out of handle_no_error()

Bug 12704861.

Bug 12704861 fix was revno: 3504.1.1 (rb://693)
Bug 12612184 fix was revno: 3445.1.10 (rb://678)

Problem: commit_1innodb fails on pb2 after the patch for BUG#11758262
Background: Certain statements threw warnings only in statement mode causing
the result cintent mismatch.

Fix: disabled warnings from the statements.

Changes in client plugin needed for testing the issue (test instrumentation).

and fix some Swedish too.

Binary log of master can get a partially logged event if the server
runs out of disk space and, while waiting for some space to be freed,
is shut down (or crashes). If the server is not stopped, it will just
wait endlessly for space to be freed, thus no partial event anomaly
occurs.  The restarted master server has had a dubious policy to send
the incomplete event to slave which it apparently can't handle.
Although an error was printed out the fact of sending with unclear
error message is a source of confusion.
Actually the problem of presence an incomplete event in the binary log
was already fixed by WL 5493 (which was merged to our current trunk
branch, major version 5.6). The fix makes the server truncate the
binary log on server restart and recovery.

However 5.5 master can't do that. So the current issue is a problem of
sending incomplete events to the slave by 5.5 master.

It is fixed in this patch by changing the policy so that only complete
events are pushed by the dump thread to the IO thread. In addition,
the error text that master sends to the slave when an incomplete event
is found, now states that incomplete event may have been caused by an
out-of-disk space situation and provides coordinates of
the first and the last event bytes read.