WL5353 introduced a new optional Binlog row event format 
containing 'extra row information'.  This is used to transfer row
transaction ids.  The addition of extra row information was not
backwards compatible, so it was possible for user error to result in 
a Slave crash for example.

To ensure that inadvertant use of the new row event format does
not cause any problems, this patch modifies the row event ids, so that
old Slaves which do not understand the new format will not attempt to
process the events.

To ensure that online upgrades are possible, a new MySQLD option is added.
--log-bin-use-v1-row-events=1 will cause MySQLD to use the original
'v1' Binlog row events, which older slaves will understand.
--log-bin-use-v1-row-events=0 will cause MySQLD to use the new 
'v2' Binlog row events, which are capable of carrying row transaction
ids.

The --ndb-log-transaction-id option can only be set to on when v2
row events are being generated, e.g. when --log-bin-use-v1-row-events=0.

By default, mysql-5.1-telco-7.0 and mysql-5.1-telco-7.1 generate v1
row events (--log-bin-use-v1-row-events=1).  mysql-5.5-cluster (7.2) 
generates v2 events (--log-bin-use-v1-row-events=0).  This implies
that row based replication from a mysql-5.5-cluster Master to an 
old mysql-5.1-telco-7.[0|1] Slave will not work, unless the mysql-5.5-cluster
Master has --log-bin-use-v1-row-events=1 set explicitly.  

Note that this option is only required for replicating to _old_ servers,
without support for v2 Binlog events.