From: Frazer Clement <frazer.clement@oracle.com>

Bug #27831990 NDB : NDB_RESTORE DOES NOT RESTORE AUTOINC CORRECTLY VIA STAGING TABLES

Part 1/3 : Add testcase showing various auto-increment backup + restore
behaviours, including staging table restore

Part 2/3  Unify handling of autoincrement restore

Current handling is separate for :
a) Restore of DATA value from SYSTAB_0
   Mechanism added to support case where there's no data for the
   table being restored
b) Restore of data in a table
   Cumulative total is tracked on the tableS object and
   applied at the end of the restore

Changes :
1) The autoincrement data is removed from tableS, which is really
   a const object of the infrastructure, and put into a separate place
   under control of consumer_restore, where it is more easily located
2) The SYSTAB_0 restore path uses this new place, rather than directly
   modifying the database
3) The value tracked is the 'next' value to be put into SYSTAB_0, not
   the max value seen.

This unification reduces the overall complexity of restoring
autoincrement values.

Part 3/3 Re-enable restore of auto-inc data for tables restored via staging

This mechanism is re-enabled.  Presumably it was disabled due to the
m_new_tables array referring to the (dropped) staging table at the
time finalize_table() was called.

This is corrected, and the mechanism re-enabled.

Bug #27832033 NDB : NDB_RESTORE DOES NOT RESTORE AUTOINC ATOMICALLY

Non atomic read, modify, write in the finalize_table() stage of
ndb_restore is replaced with an atomic condition update.  This
makes autoinc modification atomic wrt multiple ndb_restore instances
running in parallel.

This assumes that a row in SYSTAB_0 exists to be updated.

ndb_restore --restore-meta is modified to create such a row for
any table created with an autoincrement column.
MySQLD already does this.

The change to ndb_restore --restore-meta results in a testcase
output change.

Bug #27917769 NDB : NDB_RESTORE INCONSISTENT HANDLING OF SYSTAB_0

ndb_restore handles auto-increment values as follows :
 - Intervenes in the restore of SYSTAB_0 entries from the Data file
   - Maps the backup tableid to the target tableid
   - Directly sets the auto-increment value of the target tableid in the
cluster.
   - Does not restore any non-table based auto-increment values

 - Continues to maintain 'max' auto_increment values as Data and Log are
applied
   - Sets the table's final value at the end of the backup if it's > the
stored version

This approach is not correct as the SYSTAB_0 backup log content continues
to be applied directly based on tableid, so may trample the auto-increment
values stored in SYSTAB_0 for unrelated tables.

This is fixed by blocking SYSTAB_0 log apply.