MDEV-27536 invalid BINLOG_BASE64_EVENT and assertion Diagnostics_area:: !is_set()

The assert was caused by an error of XA transaction that had
BINLOG 'base64_string' statement.
The statement failed because of lack of checking whether the encoded
replication event was handled by the slave applier thread.
If it's not the slave applier no error should be generated, but it was
in this case, see a test added.

Fixed along with the idea borrowed the upstream to introduce a check
of which applier executes the replication event and do not
report any error if the applier is a regular server client.

mysql-test/suite/binlog/r/binlog_xa_handling.result

+connection default;
+CREATE TABLE t1(f1 int) ENGINE=Innodb;
+XA START '','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END '';
+XA PREPARE '';
+XA ROLLBACK '';
+DROP TABLE t1;

mysql-test/suite/binlog/t/binlog_xa_handling.test

+###############################################################################
+# Bug#19928622: ASSERTION `! IS_SET()' FAILED. | ABORT IN
+# DIAGNOSTICS_AREA::SET_OK_STATUS
+#
+# MDEV-27536 Invalid BINLOG_BASE64_EVENT and assertion Diagnostics_area:: !is_set()
+#
+# Test:
+# =====
+# Begin an XA transaction and execte a DML statement so that XA state becomes
+# XA_ACTIVE. Execute the BINLOG command it should not cause any assert.
+# Execution should be successful.
+###############################################################################
+--source include/have_log_bin.inc
+--source include/have_innodb.inc
+
+--connection default
+CREATE TABLE t1(f1 int) ENGINE=Innodb;
+
+XA START '','';
+INSERT INTO t1 VALUES(10);
+BINLOG '
+SOgWTg8BAAAAbgAAAHIAAAAAAAQANS42LjMtbTUtZGVidWctbG9nAAAAAAAAAAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAAABI6BZOEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAAVAYI8=';
+XA END '';
+XA PREPARE '';
+XA ROLLBACK '';
+
+DROP TABLE t1;

sql/log_event.cc

@@ -6167,7 +6167,8 @@ int Format_description_log_event::do_apply_event(rpl_group_info *rgi)
     original place when it comes to us; we'll know this by checking
     log_pos ("artificial" events have log_pos == 0).
   */
-  if (!is_artificial_event() && created && thd->transaction.all.ha_list)
+  if (!thd->rli_fake &&
+      !is_artificial_event() && created && thd->transaction.all.ha_list)
   {
     /* This is not an error (XA is safe), just an information */
     rli->report(INFORMATION_LEVEL, 0, NULL,