the reason for the failure is that io thread passes through a sequence of state
changes before it eventually got stuck at the expect running state as NO.
It's unreasonble to wait for the running status while the whole idea of the test is
to get to the IO thread error.

Fixed with changing the waiting condition.

Many dump threads can exist due to a way the new version of mtr governs suites.

For this immediate problem the test is refined not to use I_S but rather to reconnect
explicitly with preserving logics of a an old target bug fixes verification.

Note: item->null_value is not updated before a call to
item->store(), item->is_null() is not too (in common case).

build)

The crash was caused by freeing the internal parser stack during the parser
execution.
This occured only for complex stored procedures, after reallocating the parser
stack using my_yyoverflow(), with the following C call stack:
- MYSQLparse()
- any rule calling sp_head::restore_lex()
- lex_end()
- x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)

The root cause is the implementation of stored procedures, which breaks the
assumption from 4.1 that there is only one LEX structure per parser call.

The solution is to separate the LEX structure into:
- attributes that represent a statement (the current LEX structure),
- attributes that relate to the syntax parser itself (Yacc_state),
so that parsing multiple statements in stored programs can create multiple
LEX structures while not changing the unique Yacc_state.

Now, Yacc_state and the existing Lex_input_stream are aggregated into
Parser_state, a structure that represent the complete state of the (Lexical +
Syntax) parser.

            and value-list

The server returns unexpected results if a right side of the 
NOT IN clause consists of NULL value and some constants of
the same type, for example:

  SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2) 
  
may return 3, 4, 5 etc if a table contains these values.


The Item_func_in::val_int method has been modified:
unnecessary resets of an Item_func_case::has_null field 
value has been moved outside of an argument comparison
loop. (Also unnecessary re-initialization of the null_value
field has been moved).

offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.

Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.

Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.

offset for time part in UUIDs was 1/1000 of what it
should be. In other words, offset was off.

Also handle the case where we count into the future
when several UUIDs are generated in one "tick", and
then the next call is late enough for us to unwind
some but not all of those borrowed ticks.

Lastly, handle the case where we keep borrowing and
borrowing until the tick-counter overflows by also
changing into a new "numberspace" by creating a new
random suffix.

Problem: reading/writing data from/to an address without proper
alignment leads to SIGBUS on some platforms.

Fix: use the correct data type when dereferencing variable values.

   "funcs_2: The tests do not check if optional character
               sets exist."
2. Minor cleanup

The problem is that relying on the output of the 'ls' command is not
portable as its behavior is not the same between systems and it might
even not be available at all in (Windows).

So I added list_files that relies on the portable mysys library instead.
(and also list_files_write_file and list_files_append_file,
since the test was using '--exec ls' in that way.)

Fixed the test to expect the correct result.
The previous test script was in fact affected by 26030,
and wrongly expected a ER_PARSE_ERROR error.