WL#8007: GCS: Server Interfaces

Affects: Server-5.7   —   Status: Complete

This worklog is aimed at modularization and creation of interfaces, that shall
be useful to not only to GCS but also for future developments in Replication
projects.
Functional Requirements:

F-1: All interested server plugins shall be informed of the current 
Server Status progress, in form of a Server callback

F-2: All interested server plugins shall be informed of the current 
Transaction Status progress, in form of a Server callback

F-3: All interested server plugins shall be informed of the current 
SQL Thread progress, in form of a Server callback

F-4: A generic interface to apply Replication Events shall be provided

F-5: The generic interface must be flexible in order to create a pipeline of event 
processors

Non-Functional Requirements:

NF-1: No data shall be changed in the server as result of the 
interface callbacks
1. Context

In the GCS Project, one created several server interfaces in order
to decouple server logic from the plugin logic, to avoid having strong
dependencies from within the server, thus making the code more modular,
allowing GCS to be pluggable. Those ideas have a parallel in the
work done with the Semi-Synch Replication plugin.

Notable examples as server interfaces from the GCS project are:
  - Transaction lifetime: an interface was created in order to inform the
    plugins that a transaction is about to be committed
  - Server state: an interface was created in order to inform the
    plugins in which state the server is. For instance, if it is
    shutting down, starting up, ...

2. QA and performance assessment

In order to provide proper coverage of this WL, we added an example plugin: 
Replication Observers plugin. It will allow us to create tests that will assess 
the correctness of the implementation of the Server Hooks. 

The hooks that will be under our tests are:

Server State
- before_handle_connection: Called before a new client connection.
- before_recovery: Called before the server initializes all recovery procedures.
- after_engine_recovery: After binlog engine is ready.
- after_recovery: Called after the server ends all recovery procedures.
- before_server_shutdown: Called before the server starts a shut down.
- after_server_shutdown: Called after the server starts a shut down.

Transaction
- before_commit: Called before a transaction is committed.
- before_rollback: Called before a transaction is rollback.
- after_commit: Called after a transaction is committed.
- after_rollback: Called after a transaction is rollback.

Event control and SQL/IO thread handling.
- after_reset_slave: Called after a RESET SLAVE is invoked
- thread_start: Called when the IO Thread starts
- before_request_transmit: Called before the slave requests the events
                           from a master.
- after_read_event: Called after an event is received.
- after_queue_event: Called after an event is queued.
- consumer_thread_stop: Called after the SQL Thread is stopped
- thread_stop: Called after the IO Thread is stopped.