On QA request, adding test that causes new code to be called. 
Even if we cannot validate the result, this will at least increase the code coverage.

Patch contributed by Alex Budovski.

Conflicts:
  - sql/sys_vars.cc

Null merge the fix for Bug#49894

The number for MYSQL_REPLICATION_PLUGIN was shifted when backporting
because MYSQL_AUDIT_PLUGIN was not backported.

This problem is fixed by backporting only the number of audit plugin
and print an error when trying to load audit plugins. Note that
replication plugins compiled against old MYSQL_REPLICATION_PLUGIN
number will also be recognized as audit plugin and be rejected.

include/mysql/plugin.h:
  backporting the number of audit plugin (MYSQL_AUDIT_PLUGIN)
sql/sql_plugin.cc:
  backporting the number of audit plugin (MYSQL_AUDIT_PLUGIN)
  print an error when trying to load audit plugins

left unchanged on patch for BUG#50192.

Conflicts:
  - configure.in

Conflicts:
  - configure.in

Conflicts:
  - sql/sql_show.cc

Conflicts:
  - sql/sql_select.cc

Conflicts:
  - configure.in
  - mysql-test/include/setup_fake_relay_log.inc
  - sql/sql_select.cc

           
Conflicts
=========
Text conflict in sql/repl_failsafe.cc

Additional changes
==================
Replace references to pthread_mutex with mysql_mutex

fails in PB sporadically)
      
The IO thread can concurrently access the relay log IO_CACHE
while another thread is performing an FLUSH LOGS procedure.
      
FLUSH LOGS closes and reopens the relay log and while doing so it
(re)initializes its IO_CACHE. During this procedure the IO_CACHE
mutex is also reinitialized, which can cause problems if some
other thread (namely the IO THREAD) is concurrently accessing it
at the time .
      
This patch fixes the problem by extending the interface of the
flush_master_info function to also include a second paramater, 
"need_relay_log_lock", stating whether the thread should grab the 
relay log lock or not before actually flushing the relay log. 
Also, IO thread now calls flush_master_info with this flag set 
when it flushes master info with in the event read_event loop.

Finally, we also increase loop time in rpl_heartbeat_basic test 
case, so that the number of calls to flush logs doubles, stressing
this part of the code a little more.

mysql-test/suite/rpl/t/rpl_heartbeat_basic.test:
  Doubled the number of iterations on the FLUSH LOGS loop by
  doubling the time available to perform all iterations.
sql/repl_failsafe.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/rpl_mi.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/rpl_mi.h:
  Changed flush_master_info interface. Now takes a second parameter
  instead of just one. The second parameter is: need_lock_relay_log.
sql/rpl_rli.cc:
  Small fix in comment.
sql/slave.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.
sql/sql_repl.cc:
  Updating flush_master_info call so that it uses two parameters
  instead of one.

Conflicts:
  - sql/mysqld.cc

Conflicts:
  - mysql-test/t/bug46080.test

Conflicts:
  - mysql-test/collections/default.experimental
  - mysql-test/suite/rpl/r/rpl_sp.result

path names than 99 characters, using the USTAR format of the
resulting source TAR.

To be able to specify the use of USTAR when creating the source
TAR, we needed both to update the GNU autotools version requirements
slightly, and update the initiation of the tools to use more
modern constructs.

  fulltext search and row op.

The search for fulltext indexes is searching for some special 
predicate layouts. While doing so it's not checking for the number
of columns of the expressions it tries to calculate.
And since row expressions can't return a single scalar value there
was a crash.
Fixed by checking if the expressions are scalar (in addition to 
being constant) before calling Item::val_xxx() methods.

--default-character-set and --character-set-server such
that only the first will give a deprecation warning.
Apart from that, the two options should do the same.

The test case rpl_binlog_corruption fails on windows because when
adding a line to the binary log index file it gets terminated
with a CR+LF (which btw, is the normal case in windows, but not on
Unixes - LF). This causes mismatch between the relay log names,
causing mysqld to report that it cannot find the log file.

We fix this by creating the instrumented index file through
mysql, ie, using SELECT ... INTO DUMPFILE ..., as opposed on
relying on ultimatly OS commands like: -- echo "..." >
index. These changes go into the file and make the procedure
platform independent:

  include/setup_fake_relay_log.inc

Side note: when using SELECT ... INTO DUMPFILE ..., one needs to
check if mysqld is running with secure_file_priv. If it is, we do
it in two steps: 1. create the file on the allowed location;
2. move it to the datadir. If it is not, then we just create the
file directly on the datadir (so previous step 2. is not needed).

Original revision:
------------------------------------------------------------
revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
committer: <Li-Bing.Song@sun.com>
branch nick: mysql-5.1-bugteam
timestamp: Sat 2010-01-30 20:49:25 +0800
message:
  Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
              REVOKE/GRANT; ALTER EVENT.
  
  The following statements support the CURRENT_USER() where a user is needed.
    DROP USER 
    RENAME USER CURRENT_USER() ...
    GRANT ... TO CURRENT_USER()
    REVOKE ... FROM CURRENT_USER()
    ALTER DEFINER = CURRENT_USER() EVENT
  but, When these statements are binlogged, CURRENT_USER() just is binlogged
  as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
  executes the log event, 'CURRENT_USER()' is expand to the user of slave 
  SQL thread, but SQL thread's user name always NULL. This breaks the replication.
  
  After this patch, All above statements are rewritten when they are binlogged.
  The CURRENT_USER() is expanded to the real user's name and host.
------------------------------------------------------------

storage/myisammrg/ha_myisammrg.cc:
  myisam pointer is not relevant if a error was raised.

Linux x86_64 debug

Two test cases fail because the suppression for the unsafe
warning needs to be updated (BUG@39934 refactored this part and
these changes are only in mysql-next-mr - this is why we notice
them now when merging in next-mr). This is the case for
rpl_nondeterministic_functions and rpl_misc_functions test
cases. rpl_stm_binlog_direct test case is not needed in version >
5.1. The rpl_heartbeat_basic test case fails because patch for
BUG@50397 removed the CHANGE MASTER in the slave that would set
it's period to 1/10 of the master. This would cause the test
assertion to fail.

The fixes for the issues described above are:

 - rpl_misc_functions - updated suppression message
 - rpl_nondeterministic_functions - updated suppression message
 - rpl_stm_binlog_direct - removed the test case (it is not 
                           needed in versions > 5.1)
 - rpl_heartbeat_basic - deployed instruction: 
   CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD=0.1;

Conflicts:
  - mysql-test/r/mysqld--help-win.result
  - sql/sys_vars.cc

Original revsion (in next-mr-bugfixing):
------------------------------------------------------------
revno: 2971 [merge]
revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1
committer: Alfranio Correia <alfranio.correia@sun.com>
branch nick: mysql-next-mr-bugfixing
timestamp: Thu 2010-01-21 21:05:27 +0000
message:
  BUG#46364 MyISAM transbuffer problems (NTM problem)
        
  It is well-known that due to concurrency issues, a slave can become
  inconsistent when a transaction contains updates to both transaction and
  non-transactional tables.
                      
  In a nutshell, the current code-base tries to preserve causality among the
  statements by writing non-transactional statements to the txn-cache which
  is flushed upon commit. However, modifications done to non-transactional
  tables on behalf of a transaction become immediately visible to other
  connections but may not immediately get into the binary log and therefore
  consistency may be broken.
              
  In general, it is impossible to automatically detect causality/dependency
  among statements by just analyzing the statements sent to the server. This
  happen because dependency may be hidden in the application code and it is
  necessary to know a priori all the statements processed in the context of
  a transaction such as in a procedure. Moreover, even for the few cases that
  we could automatically address in the server, the computation effort
  required could make the approach infeasible.
              
  So, in this patch we introduce the option
        - "--binlog-direct-non-transactional-updates" that can be used to bypass
        the current behavior in order to write directly to binary log statements
        that change non-transactional tables.
  
  Besides, it is used to enable the WL#2687 which is disabled by default.
    ------------------------------------------------------------
    revno: 2970.1.1
    revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0
    parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0
    committer: Alfranio Correia <alfranio.correia@sun.com>
    branch nick: mysql-next-mr-bugfixing
    timestamp: Thu 2010-01-21 13:10:34 +0000
    message:
      BUG#46364 MyISAM transbuffer problems (NTM problem)
            
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables.
                          
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
                  
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
                  
      So, in this patch we introduce the option
            - "--binlog-direct-non-transactional-updates" that can be used to bypass
            the current behavior in order to write directly to binary log statements
            that change non-transactional tables.
      
      Besides, it is used to enable the WL#2687 which is disabled by default.

binlog_direct_non_transactional_updates_basic.result. They will
be added by a cherry-picking merge from mysql-next-mr-bugfixing
(Bug#50766).

resulution of bug #46895.