Consolidate replica-side event group filtering

Despite the result being the same - skip applying an event group, each type of filtering is done at different code locations and therefore at different times.

• The code for CHANGE MASTER TO filters and @@replicate_same_server_id are in the IO thread.
  • This means these events are not queued into the relay log.
    • Therefore, unlike those done in an SQL thread, changes to @@replicate_same_server_id only apply to newly logged event groups.
      It does not matter for CHANGE MASTER, which resets the relay log.
    • The IO thread still has to write a position update to the relay log so the SQL thread is aware of the skips, which can cause MDEV-33268.
  • do_filter() and is_group_filtered() are also hundreds of lines apart.
• @@gtid_ignore_duplicates - and only this one - is done at an SQL thread.
  • Serial and parallel replication modes have large portions of separate code for the same components, @@gtid_ignore_duplicates among them. (MDEV-30458)
• @@replicate_same_server_id (again), @@sql_slave_skip_counter and replicate_events_marked_for_skip=FILTER_ON_SLAVE are done in the OOP classes of events themselves.
  • Perhaps the intent was to let the event objects "self-report" if they should be skipped.
    But each override boils down to either "don't decrement @@sql_slave_skip_counter when skipping" or "never skip".
    This is a sign that event objects really only need to report to their SQL thread if they are one of these two types, both of which probably already have existing code used somewhere else.