With introduction of new data-dictionary in MySQL 8.0, much of foreign key
handling in DDL statements has been moved from SEs to SQL-layer.
In particular, we have moved automatical generation of names for foreign
keys, in cases when such names were not provided by user, to SQL-layer.
These names were stored in the data-dictionary, used for metadata locking
and in error messages. For all storage engines such names had form
"<table_name>_ibfk_<number>", so they were aligned with names which were
generated by InnoDB SE in 5.7.

However, NDB SE still continued to use different format for such generated
names internally -- "fk_<some_internal_id>_<other_internal_id>" instead of
using names generated by SQL-layer and stored in DD.

As result this created some issues:
- Discrepancies in SHOW CREATE TABLE output and I_S.REFENTIAL_CONSTRAINTS
  contents.
- Improper MDL locking for foreign keys (since it relies on names
  generated by SQL-layer).
- Confusing names of foreign keys in error messages.

This patch solves these issues by changing NDB SE to use generated foreign
key names from SQL-layer. However, since "<table_name>_ibfk_<number>"
pattern looks too InnoDB-specific, more generic ""<table_name>_fk_<number>"
pattern is used instead for NDB tables. InnoDB continues to use the old,
backward compatible pattern.

To support this SE API and SQL-layer code were extended to support different
FK name suffixes in generated FK names for different engines.

This is incompatible change for NDB tables, which breaks replication of
ALTER TABLE ... DROP FOREIGN KEY statements for such tables from 5.7 masters
to 8.0 slaves. However, this should not be a big issue as replication of
such statements was not robust, anyway, as it relied on internal NDB
table IDs on master and slave being the same.

Reviewed-by: Sivert Sorumgaard <sivert.sorumgaard@oracle.com>
Reviewed-by: Lakshmi Narayanan Sreethar <lakshmi.narayanan.sreethar@oracle.com>