MDEV-28530: Revoking privileges from a non-existing user on a master breaks replication on the slave in the presence of replication filtersbb-10.2-MDEV-28530

Problem:
========
Replication can break while applying a query log event if its
respective command errors on the primary, but is ignored by the
replication filter within Grant_tables on the replica. The bug
reported by MDEV-28530 shows this with REVOKE ALL PRIVILEGES using a
non-existent user. The primary will binlog the REVOKE command with
an error code, and the replica will think the command executed with
success because the replication filter will ignore the command while
accessing the Grant_tables classes. When the replica performs an
error check, it sees the difference between the error codes, and
replication breaks.

Solution:
========
If the replication filter check done by Grant_tables logic ignores
the tables, reset thd->slave_expected_error to 0 so that
Query_log_event::do_apply_event() can be made aware that the
underlying query was ignored when it compares errors.

Note that this bug also effects DROP USER if not all users exist
in the provided list, and the patch fixes and tests this case.

Reviewed By:
============
<TODO>

1 files changed, 6 insertions, 0 deletions

diff --git a/sql/log_event.cc b/sql/log_event.cc
index f8373202750..c0c3bd4acbe 100644
--- a/sql/log_event.cc
+++ b/sql/log_event.cc
@@ -5357,6 +5357,12 @@ int Query_log_event::do_apply_event(rpl_group_info *rgi,
         thd->update_server_status();
         log_slow_statement(thd);
         thd->lex->restore_set_statement_var();
+
+        /*
+          slave_expected_error can be reset if the targeted tables are ignored
+          by the replication filter
+        */
+        expected_error= thd->slave_expected_error;
       }
 
       thd->variables.option_bits&= ~OPTION_MASTER_SQL_ERROR;