WL#2952: Transaction Support in Federated Handler

Affects: Server-7.0   —   Status: On-Hold   —   Priority: Low

Implemented in multiple stages:

Stage 1
* Create a transaction context.
* Create a connection for each table in a transaction context.

Stage 2
* Implement per-table connection pooling

Stage 3
* Implement per-server connection pooling

Stage 4 (optional)
* Allow differing 'backend' transports to be used such as ODBC.

Stage 5 (optional)
* Implement XA support for two phase commit.

Implement the handler methods and handlerton functions for commit, rollback, 
external_lock, etc.

Stage 1
* Create a transaction class federated_trx
* Create a transport class federated_io

Stage 2
* Implement simple LIFO queue in per-table shared structure.

Stage 3
* Implement a cache for per-server information
* Move LIFO transport queue into per-server structure

Stage 4 (optional)
* Declare federated_io class as a abstract virtual class.
* Declare new classes for implementing transports.

Stage 5 (optional)
* When beginning a transaction, either copy the MySQL XID or create a new
  one for use by Federated transports.
* When a connection joins a transaction, begin the XA transaction using the
  stored XID.
* If a cycle is detected (responsibility of remote XA server to detect) then
  an error must be reported.
* XA functionality should be optional.
Eventually, we will wish to discover all attributes of a remote table, but
for the moment, we will make some assumptions.

At present, the connection assumes autocommit is true, first we will change
this assumption.

When a federated handler object has open table called, we will issue a
"SET AUTOCOMMIT=0" then, at each "commit", we will issue a "COMMIT" on the
remote table.

We will add a "federated_trx_data" struct to hold pointers to the handlers 
involved in
a transaction.

implement the "commit" and "rollback" functions for the federated handlerton
and "ha_federated::external_lock"