mysql_install_db or mysql_upgrade fails when default_engine=archive

User `akv' reported on IRC the problem.

The my.cnf has default engine set to archive.

When mysql_install_db or mysql_upgrade runs, it tries to create the
mysql.gtid_slave_pos table with the default storage engine. This fails because
the archive storage engine apparently does not support a key length of 12
bytes:

"Specified key was too long; max key length is 8 bytes"

But archive can in any case not be used as the storage engine for
mysql.gtid_slave_pos, as it does not support delete.

On hindsight it seems like a pretty bad idea to create the
mysql.gtid_slave_pos with whatever table the user set as default. If an exotic
default is set, this can easyly cause install or upgrade to fail, which is
bad. The user might even eg. deliberately set an invalid default engine to
enforce explicit ENGINE= on create table statements.

So I think we need a better way to determine the default engine for
mysql.gtid_slave_pos. The idea is that for most installations we want it to be
InnoDB. However, if innodb is not available, it should still be created as
some other engine. If for example people are using TokuDB as the main engine,
the gtid_slave_pos table should also be TokuDB, otherwise XA commit will incur
a huge overhead.

I see there is already other code that checks if InnoDB is available and
selects storage engine to InnoDB or MyISAM as appropriate, that might be a
reasonable solution and then users of other engines can explicitly ALTER TABLE
mysql.gtid_slave_pos ENGINE=xxx as appropriate.