Problem:
--------

NDB tables with old metadata i.e. frm are translated on-the-fly and
stored in the DD of the MySQL server. This is done by invoking a
previously self-contained function which created a DD table object,
stored it in DD, and persisted the change through a commit (or rolled
back all changes in case of an intermediate failure).

The self-contained nature of the function was far from ideal since
from an ndbcluster plugin perspective, storing the table in the DD
is one out of multiple steps involved in a metadata change. This is
handled using the RAII nature of the Ndb_dd_client class. However,
since the table metadata upgrade code was a fork of the server
implementation, the Ndb_dd_client class wasn't used. This meant that
the DD table object was sometimes committed in the DD prematurely
and the table continued to exist in the DD even if one of the
subsequent steps was to fail.

The above issue can be seen in the auto sync mechanism, particularly
in the scenario where the synchronization of tables is skipped due
to a mismatch in terms of indexes between NDB Dictionary and DD. In
the case of a table metadata upgrade, the table is actually created
in the DD despite the mismatch being detected. This is a deviation
from the desired behaviour which is seen when dealing with sync
of tables created using 8.0 or in other words table whose metadata
doesn't have to be upgraded. In the latter case, the table is not
synced and the failure to do so is treated as a temporary error.

Fix:
----

The premature commit of the table object in DD is avoided by:

- Removing all calls to trans_commit and similar functions. The
  caller functions are now responsible for the commit or roll
  back of the DD changes
- Move the comparison logic to the auto sync code where it belongs.
  This comparison has to be done before the commit so it previously
  had to be done inside the aforementioned self-contained function
- Change all direct Dictionary_client usages to Ndb_dd_client
- Remove the set_se_data_for_user_tables as with the new
  implementation, a single handler function call is sufficient to
  set all SE-specific data

An important change from an auto sync perspective is that there's
no deviation in terms of behaviour when an index mismatch is detected
whether it's a table metadata upgrade or not. After this fix, all such
cases are treated as temporary errors

Change-Id: I6281318af202c556ff09f313d0553b64284d0444