Backport of revno: 2617.81.4

Bug #47274 assert in open_table on CREATE TABLE <already existing>

The problem was an assertion during execution of CREATE TABLES. 
This assertion would occur if INSERT DELAYED or REPLACE DELAYED
were used to update a table containing an AUTO_INCREMENT column
and if the inserted row had a user-supplied value for that column.
Any CREATE TABLE statement (including CREATE TABLE SELECT and
CREATE TABLE LIKE) trying to create the same table and 
which followed the INSERT/REPLACED would cause the assertion.

The problem was only noticeable on debug builds of the server
and not present in the mysql-5.1 tree.

The cause of the problem was that the code for delayed insert did
not properly reset the TABLE->auto_increment_if_null flag after 
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered by CREATE TABLE.

This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once INSERT/REPLACE DELAYED has updated the table, 
similar to what is done already for regular INSERT statements.

Test case added to delayed.test.

sql/sql_insert.cc

@@ -2729,6 +2729,12 @@ bool Delayed_insert::handle_inserts(void)
     thread_safe_increment(delayed_insert_writes,&LOCK_delayed_status);
     pthread_mutex_lock(&mutex);
 
+    /*
+      Reset the table->auto_increment_field_not_null as it is valid for
+      only one row.
+    */
+    table->auto_increment_field_not_null= FALSE;
+
     delete row;
     /*
       Let READ clients do something once in a while