Test MySQL to Drizzle migration via drizzledump

We are going to use a strategy similar to how we test drizzledump+restore functionality with the randgen.

We will have a MySQL server running (5.1 and 5.5), populate it with a standard set of tables in 'test', we will then create a second database in which we will create, populate and randomly alter the tables.

Once we have completed this cycle (we average ~20 tables per cycle), we will call drizzledump in 'migrate' mode:

After the call to drizzledump has returned, we will then compare dumpfiles.

Some concessions are likely needed for certain changes (such as making '0000-00-00' into NULL), but these will likely be minor.

** 10/12 update **
Have tested with all MySQL data types (NULL and NOT NULL variants).
Found some issues with DATE/DATETIME & '0000-00-00' dates as well as some issues with blob (see bugs list).
All other data types pass perfectly.

10/25 update
Testing continues a bit longer. More scenarios have come to mind / have been found by our community members

11/22 - tied up with transaction log testing - pushed back again : (

12/6 - Implemented
We changed tack on this and went with a test suite for the test-runner. Validation + coverage of all relevant cases via randgen wasn't good.

The new suite requires only a running MySQL server + a couple of environment variables to be set.
The tests work as follows:
1) Populate the MySQL server from files in std_data
2) Call Drizzledump from the tree being tested to populate drizzle
3) The tests perform various checks (usually SHOW CREATE + SELECT *)

This will be able to run anywhere with only minor requirements and we cover a wide range of relevant use cases.
Still expect to have missed some edge cases, but the basics are covered.

Tests are not fully running in Hudson slaves yet - waiting for some bug fixes to make it into trunk.