Seen in a few tests after 43418
Add code in extract_warning_lines() to skip this part

Checking is done before server is terminated
Adds post processing of server logs if --valgrind
Also had to remove --quiet option to valgrind

Some output is written, some is not
Finally concluded it's a Perl bug: after running with parallel threads
  for a while, print suddenly ignores all but the first argument.
Workaround: concatenate all the arguments into one, except in output that
  only comes before we start running tests

Prepend "Completed", "Timeout" or "Too many failed" to summary line

There's no need for --verbose for the mysqltest in check-warnings, remove it

Knowledge of no SSL support is not used
Skip tests the same way e.g. innodb tests are
Does not refer to have_ssl_communication.inc, 
     will add this when merging to 6.0-codebase

Don't print entire log, but use extract_server_log() introduced by 46007

Test batches may be terminated too early
Avoid counting exp-fail tests

Use "#ifdef", not plain "#if".

Temporary tables may set join->group to 0 even though there is 
grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
decides whether to present results in a grouped manner.

            columns without where/group
                     
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
                              
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
                  
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
                  
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.