Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH MASTER-MASTER AND USING SET USE
Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH
MASTER-MASTER AND USING SET USE

Problem:
=======
In a master-master set-up, a master can show a wrong
'SHOW SLAVE STATUS' output.

Requirements:
- master-master
- log_slave_updates

This is caused when using SET user-variables and then using
it to perform writes. From then on the master that performed
the insert will have a SHOW SLAVE STATUS that is wrong and  
it will never get updated until a write happens on the other
master. On"Master A" the "exec_master_log_pos" is not
getting updated.

Analysis:
========
Slave receives a "User_var" event from the master and after
applying the event, when "log_slave_updates" option is
enabled the slave tries to write this applied event into
its own binary log. At the time of writing this event the
slave should use the "originating server-id". But in the
above case the sever always logs the  "user var events"
by using its global server-id. Due to this in a
"master-master" replication when the event comes back to the
originating server the "User_var_event" doesn't get skipped.
"User_var_events" are context based events and they always
follow with a query event which marks their end of group.
Due to the above mentioned problem with "User_var_event"
logging the "User_var_event" never gets skipped where as
its corresponding "query_event" gets skipped. Hence the
"User_var" event always waits for the next "query event"
and the "Exec_master_log_position" does not get updated
properly.

Fix:
===
`MYSQL_BIN_LOG::write' function is used to write events
into binary log. Within this function a new object for
"User_var_log_event" is created and this new object is used
to write the "User_var" event in the binlog. "User var"
event is inherited from "Log_event". This "Log_event" has
different overloaded constructors. When a "THD" object
is present "Log_event(thd,...)" constructor should be used
to initialise the objects and in the absence of a valid
"THD" object "Log_event()" minimal constructor should be
used. In the above mentioned problem always default minimal
constructor was used which is incorrect. This minimal
constructor is replaced with "Log_event(thd,...)".

sql/log_event.h:
  Replaced the default constructor with another constructor
  which takes "THD" object as an argument.

ollie314/server,ollie314/server,davidl-zend/zenddbi,ollie314/server,davidl-zend/zenddbi,slanterns/server,davidl-zend/zenddbi,ollie314/server,ollie314/server,davidl-zend/zenddbi,natsys/mariadb_10.2,davidl-zend/zenddbi,davidl-zend/zenddbi,flynn1973/mariadb-aix,flynn1973/mariadb-aix,ollie314/server,ollie314/server,natsys/mariadb_10.2,natsys/mariadb_10.2,davidl-zend/zenddbi,flynn1973/mariadb-aix,natsys/mariadb_10.2,ollie314/server,davidl-zend/zenddbi,ollie314/server,flynn1973/mariadb-aix,flynn1973/mariadb-aix,flynn1973/mariadb-aix,flynn1973/mariadb-aix,davidl-zend/zenddbi,natsys/mariadb_10.2,natsys/mariadb_10.2,ollie314/server,natsys/mariadb_10.2,flynn1973/mariadb-aix,flynn1973/mariadb-aix,davidl-zend/zenddbi,natsys/mariadb_10.2,natsys/mariadb_10.2,davidl-zend/zenddbi,natsys/mariadb_10.2,ollie314/server,natsys/mariadb_10.2,flynn1973/mariadb-aix,flynn1973/mariadb-aix