perl 

The problem here was the method how MTR gets its unique thread ids.
Prior to this patch, the method to do it was to maintain a global 
table of pid,mtr_unique_id) pairs. The table was backed by a text 
file. The table was cleaned up one in a while and dead processes leaking
unique_ids were determined with with kill(0) or with scripting tasklist
on Windows.

This method is flawed specifically on native Windows Perl. fork() is 
implemented with starting a new thread, give it a syntetic negative PID
(threadID*(-1)), until this thread creates a new process with exec()
However,  neither tasklist nor any other native Windows tool can cope with
negative perl PIDs. This lead to incorrect determination of dead process 
and reusing already used mtr_unique_id.

The patch introduces alternative portable  method of solving unique-id 
problem. When a process needs a unique id in range [min...max], it just 
starts  to open files named min, min+1,...max in a loop . After file is 
opened, we do non-blocking flock(). When flock() succeeds, process has 
allocated the ID. When process dies, file is unlocked . Checks for zombies 
are not necessary.

Since the change would create a co-existence problems with older version
of MTR, because of different way to calculate IDs, the default ID range
is changed from 250-299 to 300-349.

Another fix that was necessary enable --parallel option was to serialize 
spawn() calls on Windows. specifically, IO redirects needed to be protected.

This patch also fixes hanging CRTL-C (as described in Bug #38629) for the
"new"  MTR. The fix was already in 6.0 and is now downported.

Potentially infinite loop in check_expected_crash_and_restart 
Replace with finite loop and some additional logic

mtr *thinks* there's a side effect
Use the new force_restart() to avoid running the check-testcase

Hangs when trying to copy the pipe
Amend copytree() to only copy regular files

option
In practice, only the last run of the test was counted
Add a separate counter rep_failures for failures before last run

 - Properly update .result file

 - Update testcases funcs_1.is_routines to only query
   information_schema.routines about the routines in 'test'
   database(where it has created it's routines)

 - Some tests need to modify the server(s) so much that a total restart of all servers are
   necessary after test. Make it possible for a test to signal it want mtr.pl to restart
   all servers.

Only count non-retried tests, and increment before testing

Test was flakey on some machines and showed spurious
reds for races.

New-and-improved test makes do with fewer statements,
no mysqltest-variables, and no backticks. Should hope-
fully be more robust. Heck, it's debatable whether we
should have a test for this, anyway.

If suite specified as part of test name, collect from that suite too.

It leads to crash because there is no OOM check in ha_archive::unpack_row().
The fix:
added OOM error check

compilation warning fixed

due to name_const substitution

Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".

For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.

Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().

Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").

manual merge. also adds test specific to 5.1+

Fine-tuning. Broke out comparison into method by
suggestion of Davi. Clarified comments. Reverting
test-case which I find too brittle; proper test
case in 5.1+.

(Pushing for Azundris)
      
We allow security-contexts with NULL users (for
system-threads and for unauthenticated users).
If a non-SUPER-user tried to KILL such a thread,
we tried to compare the user-fields to see whether
they owned that thread. Comparing against NULL was
not a good idea.
      
If KILLer does not have SUPER-privilege, we
specifically check whether both KILLer and KILLee
have a non-NULL user before testing for string-
equality. If either is NULL, we reject the KILL.

            
The issue happened to be two-fold.
The table map event was recorded into binlog having
an incorrect size when number of columns exceeded 251. 
The Row-based event had incorrect recording and restoring m_width member within
the same as above conditions.

Fixed with correcting m_data_size and m_width.