Replication info files are not being flushed and synced when the
command 'STOP SLAVE' is issued. This means that one cannot just
rely on existing values on those files when the slave has been
stopped. Having consistent, uncorrupted and up-to-date info files
when stopping the slave would be most useful, for instance, for
snapshotting purposes (a procedure that is often used for
restoring slaves).
      
This patch addresses this by instrumenting the
terminate_slave_threads function so that it also flushes and
syncs the *info files as well as the relay log whenever it gets
called, ie, on 'STOP SLAVE'.  Although this imposes a performance
trade-off (specifically when stopping the slave), it should have
no negative influence on overall replication performance (impact
is only noticeable on 'STOP SLAVE').

Create a set of test cases to see if some DDL statements implicitly commit
a transaction on the NDB and are written directly to the binary log without
going through either the Statement- or Transactional-Cache.

merging 5.1 main -> 5.1-rep+2 -> 5.1-rep+3; binlog_unsafe , rpl_mysql_upgrade fail and are under treatment

Non-transactional updates that take place inside a transaction present problems
for logging because they are visible to other clients before the transaction
is committed, and they are not rolled back even if the transaction is rolled
back. It is not always possible to log correctly in statement format when both
transactional and non-transactional tables are used in the same transaction.

In the current patch, we ensure that such scenario is completely safe under the
ROW and MIXED modes.

Postfix

      
      Before the patch, slaves only appear in the output of SHOW SLAVE HOSTS 
      when report-host option is set. If an expected slave does not appear in  
      the list, nobody knows whether the slave does not connect or has started
      without the "report-host" option. The output also contains a strange  
      field "Rpl_recovery_rank" which has never been implemented and the manual 
      of MySQL5.4 declares that the field has been removed from MySQL5.4.
                                        
      This patch is done with these,
      According to the manual of MySQL5.4, "Rpl_recovery_rank" is removed.
      Slaves will register themselves to master no matter if report_host option is set
      or not. When slaves are registering themselves, their Server_ids, report_host
      and other information are together sent to master. Sever_ids are never null 
      and is unique in one replication group. Slaves always can be identified with  
      different Server_ids no matter if report_host exists.

Knowledge of no SSL support is not used
Skip tests the same way e.g. innodb tests are
Does not refer to have_ssl_communication.inc, 
     will add this when merging to 6.0-codebase

Post-push fix.
Problem: In a previous patch for BUG#39934, rpl_idempotency.test
was split in two tests. The mtr suppressions in the original test
did not make it into the new test. This caused pushbuild warnings.
Fix: copy the mtr suppressions from rpl_idempotency.test to
rpl_row_idempotency.test

The rpl_ndb/combinations file was introduced as part of the fix.
The file contained an error: ndb suites shall not run with
binlog_format=mixed. Removed that combination.

post-push fixes. the test case tried to use a udf that had not been loaded. removed the udf.

rpl_semi_sync_master_wait_sessions was reset by FLUSH STATUS,
which could cause the master fail to wake up waiting sessions and
result in master timeout waiting for slave reply.

rpl_semi_sync_master_wait_session should not be reset, this 
problem is fixed by this patch.

Don't print entire log, but use extract_server_log() introduced by 46007

Test batches may be terminated too early
Avoid counting exp-fail tests

Use "#ifdef", not plain "#if".