WL#10493: Add transaction length to gtid_log_event

Add transaction length to the Gtid_log_event in the binary log.

This is a stepping stone for:

 1. Optimizing the applier. Currently, the coordinator thread dispatches one
    event at a time to the workers. This context switch is expensive, and
    becomes more of a bottleneck the more we optimize other things. If we have
    the transaction length, we can dispatch the whole transaction in just one
    context switch. Since RBR transactions use at least 5 events
    (gtid+begin+table_map+row+commit) this is a big improvement.
 2. Optimizing the protocol. Currently, we send each event in one packet. If
    we have the length easily available, it becomes easier to send each
    transaction as one packet (and split into multiple packets if that is needed
    in order to keep within max_allowed_packet).
 3. Optimizing the binlog by removing BEGIN/COMMIT events. When we have the
    length field, we can use that to detect transaction boundaries. Then the
    BEGIN/COMMIT become less important.
 4. Expose transaction size to the user through performance_schema tables.

Functional requirements
-----------------------

F-1: A server with support for this feature must always log the transaction
     length of transactions applied (and binary logged) into Gtid_log_event.

F-2: Non-applied (injected) transactions may let the transaction length field
     set to 0. Those are transactions generated and injected into relay logs to
     be applied. Once applied, the correspondent Gtid on binary log must have
     the correct transaction length.

F-3: A server without support for this feature shall be able to apply events
     generated from a server that supports the feature, but without the ability
     to take benefit of the transaction length information.

F-4: A transaction replicated from a server without support for this feature,
     when replicated to a server with support for this feature, shall have no
     transaction length information on the relay log, but must generate it once
     applying the transaction and logging it to the binary log.

F-5: The transaction length information is not designed to be preserved across
     distinct server's binary logs, but it shall be preserved between a master
     binary log and its slaves relays log.

F-6: The dump of mysqlbinlog client program with support for this feature must
     display the transaction length information when available, and display 0 as
     the transaction length when the Gtid_log_event was generated in a server
     without support for this feature.


Non-Functional requirements
---------------------------

NF-1: The impact on server performance introduced by logging the transaction
      length into the binary log shall be negligible.

Interface Specification
-----------------------

I-1: Introduce a new field at Gtid_log_event:
       NAME: transaction length
       TYPE: unsigned long long int using net_store_length (1 to 9 bytes)
       DESCRIPTION: Stores the transaction length in bytes (this also includes
                    the Gtid_log_event length).

I-2: No new options
I-3: No new files
I-4: No changes in existing syntax
I-5: No new commands
I-6: No new tools

High Level Specification
------------------------

The specification can be divided into two steps: (S-1) make the master to log
the transaction length on its binary log; (S-2) make mysqlbinlog to output the
transaction length information.

S-1: In order to support F-1, the Gtid_log_event should be extended to log a new
     field (defined at I-1) containing the transaction length. The idea is to
     calculate the transaction size when writing the Gtid_log_event into the
     binary log. The binary_log_cache size is the transaction size but missing
     the Gtid_log_event size and the CRC32 information for all events in the
     cache (when checksum is enabled). In order to compute the CRC32 payload on
     the transaction, we need to count the amount of events written to the binary
     log cache. This counter must take into account the possibility of SAVEPOINT
     and ROLLBACK TO SAVEPOINT be applied on the binary log cache.

S-2: In order to support F-6, a mysqbinlog client tool dumping a Gtid_log_event
     should display 0 as transaction length for the events without the
     information and will display the transaction length for those containing it.