Problem was that trx_sys->mutex was acquired to print trx info
even when we already hold trx_sys->mutex. Fixed similarly as
in InnoDB, i.e. with wsrep_trx_print_locking() function that
does not acquire trx_sys->mutex.

The test is not expected to crash. With a non-debug server,
Valgrind completes in reasonable time without any failure.

Also, it does not make sense to store and restore parameters
when the parameters are already being restored by a server restart.

Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>

- Before this patch during startup all slave threads was started without
  any check that they had started properly.
- If one did a START SLAVE, STOP SLAVE or CHANGE MASTER as first command to the server
  there was a chance that server could access structures that where not
  properly  initialized which could lead to crashes in
  Log_event::read_log_event
- Fixed by waiting for slave threads to start up properly also during
  server startup, like we do with START SLAVE.

The following is an updated commit message for the following commit
that was pushed before I had a chance to update the commit message:
c5e25c8b

Fixed dead locks when doing stop slave while slave was starting.

- Added a separate lock for protecting start/stop/reset of a specific slave.
  This solves some possible dead locks when one calls stop slave while
  the slave is starting as the old run_locks was over used for other things.
- Set hash->records to 0 before calling free of all hash elements.
  This was set to stop concurrent threads to loop over hash elements and
  access members that was already freed.
  This was a problem especially in start_all_slaves/stop_all_slaves
  as the mutex protecting the hash was temporarily released while a slave
  was started/stopped.
- Because of change to hash->records during hash_reset(),
  any_slave_sql_running() will return 1 during shutdown as one can't
  loop over master_info_index->master_info_hash while hash_reset() of it
  is in progress.
  This also fixes a potential old bug in any_slave_sql_running() where
  during shutdown and ~Master_info_index(), my_hash_free() we could
  potentially try to access elements that was already freed.

Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>

The value of wsrep_affected_rows were not reseted properly for
slave. Now we also wsrep_affected_rows in Xid_log_event::do_apply_event
also , apart from THD::cleanup_after_query().
Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>

restore mysql_file_delete_with_symlink() but let it use
new my_handler_delete_with_symlink() mysys helper.

Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

Galera MTR Tests: do not run innodb.innodb_stats_del_mark and some other tests with Galera, as it produces warnings
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

Introduced a new wsrep_trx_print_locking() which may be called
under lock_sys->mutex if the trx has locks.
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

* silenced the WSREP_ERROR, this fires for all replication filtered DDL,
  and is false positive

Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

 * remove part of galera_var_cluster_address.test that can not be tested reliably
 * reduce running time for galera_gcache_recover_manytrx.test
 * Additional wait_conditions for GAL-401.test
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

gcomm://
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

Fix symlink-aria && symlink-myisam to account for this possibility.

Option wsrep_max_ws_rows is intended to limit the maximum number of rows
in a writeset. To enforce this limit, we increment THD::wsrep_affected_rows
on every INSERT, UPDATE or DELETE. The problem is that we do so even on
insertion to internal temporary tables used for SELECTs and such.
THD::wsrep_affected_rows is now incremented only for rows that are actually
replicated.
Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

* a dedicated test for wsrep_retry_autocommit
* some galera_toi_* tests were only passing because wsrep_retry_autocommit
  was in effect. The tests were changed to do not use autocommit
* higher timeout values in galera_2nodes.cnf , galera_3nodes.cnf

# Conflicts:
#	mysql-test/suite/galera/galera_2nodes.cnf
#	mysql-test/suite/galera/r/galera_defaults.result
#	mysql-test/suite/galera_3nodes/galera_3nodes.cnf

Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>