When no :storage_engine setting is provided, use MyISAM; reset MySQL's auto increment counter when InnoDB is used

In the original article about UID servers that the global_uid gem was based on, the MyISAM engine was used in the example `CREATE TABLE` statement:

http://code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

I think this was for a good reason... InnoDB behaves strangely with respect to auto_increment columns and `UPDATE` queries, which are used in global_uid to obtain many IDs at once in `get_many_uids_for_class`.

Example:

```
2327-ggrossman:global_uid ggrossman$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7523
Server version: 5.5.20 Source distribution

Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> \u test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> create table t (id bigint(21) auto_increment, stub char(1), primary key (`id`), unique key `stub` (`stub`)) engine=InnoDB;
Query OK, 0 rows affected (0.02 sec)

mysql> replace into t (stub) values ('a');
Query OK, 1 row affected (0.01 sec)

mysql> select id from t;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.00 sec)

mysql> update t set id=id+100 where stub='a';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select id from t;
+-----+
| id  |
+-----+
| 101 |
+-----+
1 row in set (0.00 sec)

mysql> replace into t (stub) values ('a');
Query OK, 2 rows affected (0.01 sec)

mysql> select id from t;
+----+
| id |
+----+
|  2 |
+----+
1 row in set (0.00 sec)

mysql> 
```

However, if `ALTER TABLE t AUTO_INCREMENT=1` is issued after the `UPDATE` query, the ID column behaves as expected.

```
mysql> update t set id=id+100;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select id from t;
+-----+
| id  |
+-----+
| 102 |
+-----+
1 row in set (0.00 sec)

mysql> alter table t auto_increment=1;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> replace into t (stub) values ('a');
Query OK, 2 rows affected (0.01 sec)

mysql> select id from t;
+-----+
| id  |
+-----+
| 103 |
+-----+
1 row in set (0.00 sec)

mysql> 
```

### Solution

The solution I propose here is to default the MySQL storage engine to MyISAM if the `:storage_engine` setting is not provided in `global_uid_options`. To this point, global_uid has defaulted to the storage engine setting of the MySQL server, which could very well be InnoDB.

The second part of the fix is to issue `ALTER TABLE table_name AUTO_INCREMENT=1` after doing an `UPDATE` query if the InnoDB engine is being used. This `ALTER TABLE` command is sufficient to force MySQL to recalculate the auto increment counter. It doesn't actually set it to 1; it sets it to the maximum value in the auto increment column. This `ALTER TABLE` command appears to be harmless for MyISAM as well, but I've made it only happen for InnoDB to reduce risk.

/cc @eac @grosser @osheroff @vkmita @rtatsumi

### References
 - None

### Risks
 - Because we're only issuing the `ALTER TABLE` command if `global_uid_options` says the storage engine is InnoDB, there is a risk that the actual uid tables aren't using the correct MySQL storage engine, so that should be verified by the DBA.

The MySQL docs at http://dev.mysql.com/doc/refman/5.5/en/alter-table.html say:

> You cannot reset the counter to a value less than or equal to any that have already been used. For MyISAM, if the value is less than or equal to the maximum value currently in the AUTO_INCREMENT column, the value is reset to the current maximum plus one. For InnoDB, if the value is less than the current maximum value in the column, no error occurs and the current sequence value is not changed.

So, it doesn't let you really set it to 1. We could use the real maximum ID that we just obtained, but it doesn't appear to be necessary.

The 5.5 docs say that "the current sequence value is not changed", but it does do something... the `ALTER TABLE` appears to force InnoDB to flush whatever cached version of the auto_increment column it was holding and recalculate it based on the actual column contents. It's weird but it works.

Essentially, we're working around a bug in InnoDB where it doesn't catch the fact that the auto_increment column has changed.

I just tried it and the bug still exists in MySQL 5.6.17.

The wording of the docs changed slightly in MySQL 5.6, http://dev.mysql.com/doc/refman/5.6/en/alter-table.html

> You cannot reset the counter to a value less than or equal to the value that is currently in use. For both InnoDB and MyISAM, if the value is less than or equal to the maximum value currently in the AUTO_INCREMENT column, the value is reset to the current maximum AUTO_INCREMENT column value plus one.

I believe the behavior didn't change at all between 5.5 and 5.6 and they just updated the docs. So setting it to 1 is harmless and should be exactly the same as setting it to any other value less than the real maximum value in the column.

At any rate, this is just to support `get_many_uids_for_class` for InnoDB. We're not doing this `ALTER TABLE` workaround for MyISAM, and because of the other part of this fix, global_uid will default to MyISAM unless the configuration insists upon InnoDB.

Since InnoDB has this weirdness, I think we should recommend MyISAM for users of global_uid. I think at Zendesk we already are using MyISAM for alloc servers in production, looking at our configs. The table-level locking in MyISAM shouldn't be a problem for single row tables that are surely entirely cached in memory.