Problem:

When INSERT ... ON DUPLICATE UPDATE or REPLACE statements are used, then
after encountering a DB_DUPLICATE_KEY error, we continue to process all
the unique secondary indexes to place the necessary gap locks.  The
problem is in the following scenario:

1. The table has one primary index, one unique secondary index and
   one non-unique secondary index.
2. The INSERT ... ON DUPLICATE UPDATE ... is executed on the table.
3. Insert into the clustered index reported DB_DUPLICATE_KEY.  This
   error information is saved.  We proceed to take gap locks in all
   unique secondary indexes.
4. Insert into the unique secondary index reported DB_LOCK_WAIT.
5. Step 4 is repeated from a higher layer row_ins().  When this is
   done, the earlier error information saved in step 3 is lost.
6. Next instead of taking just gap locks or skipping non-unique
   secondary indexes, because of loss of information regarding the
   error already saved, an actual insert is performed on the non-unique
   secondary index.  This triggers the assert.

Solution:

Save the error information in a non-local location so that it is not lost.

rb#4723 approved by Kevin.