STATUS TABLES

Problem
-------

New fields were added by WL#7374 to following PS replication tables:
- replication_connection_status;
- replication_applier_status_by_coordinator;
- replication_applier_status_by_worker.

The fields are related to GTID monitoring. They have information about
when a GTID was committed on the original master and on the immediate
master, when a GTID transaction started being processed by the I/O
thread (connection_status), by the MTS coordinator and by the worker
threads. There is also the timing information about the last processed
transaction of the three replication thread types.

For performance reasons, if this new information is not needed, users
should be able to disable the instrumentation that populates the new
table fields. However, in the current implementation, this
instrumentation is always enabled.

Fix
---

The replication monitoring introduced by WL#7374 now depends on
performance schema being enabled on the server.

When performance schema is not enabled in the server, the replication
status tables will not collect local timing information. All
START_*_TIMESTAMP and END_*_TIMESTAMP will be zero for the new queued,
buffered and applied transactions.

We replaced all extra Relay_log_info locking just for ensuring GTID
information atomicity by a new atomic locking mechanism just for the
GTID information.

Note: this fix made also some performance schema tables as "perpetual":
- replication_applier_configuration;
- replication_applier_status;
- replication_applier_status_by_coordinator;
- replication_applier_status_by_worker;
- replication_connection_configuration;
- replication_connection_status;

Those tables should be able to present content even when performance
schema is disabled on server.