if cached query uses many tables

The problem was that query cache would not properly cache
queries which used 256 or more tables but yet would leave
behind query cache blocks pointing to freed (destroyed)
data. Later when invalidating (due to a truncate) query cache
would attempt to grab a lock which resided in the freed data,
leading to hangs or undefined behavior.

This was happening due to a improper return value from the
function responsible for registering the tables used in the
query (so the cache can be invalidated later if one of the
tables is modified). The function expected a return value of
type boolean (char, 8 bits) indicating success (1) or failure
(0) but the number of tables registered (unsigned int, 32 bits)
was being returned instead. This caused the function to return
failure for cases where it had actually succeed because when
a type (unsigned int) is converted to a narrower type (char),
the excess bits on the left are discarded. Thus if the 8
rightmost bits are zero, the return value will be 0 (failure).

The solution is to simply return true (1) only if the number of
registered table is greater than zero and false (0) otherwise.

Bug 36788 Multiple funcs_1 'trig' tests are failing on vanilla builds

Fix for this bug and additional improvements/fixes
In detail:
- Remove unicode attribute from several columns
  (unicode properties were nowhere needed/tested)
  of the table tb3
  -> The runnability of these tests depends no more on
     the availibility of some optional collations.
- Use a table tb3 with the same layout for all
  engines to be tested and unify the engine name
  within the protocols.
  -> <engine>_trig_<abc>.result have the same content
- Do not load data into tb3 if these rows have no
  impact on result sets
- Add tests for NDB (they exist already in 5.1)
- "--replace_result" at various places because
  NDB variants of tests failed with "random" row
  order in results
  This fixes a till now unknown weakness within the
  funcs_1 NDB tests existing in 5.1 and 6.0
- Fix the expected result of ndb_trig_1011ext
  which suffered from Bug 32656
  + disable this test
- funcs_1 could be executed with the mysql-test-run.pl
  option "--reorder", which saves some runtime by
  optimizing server restarts.
  Runtimes on tmpfs (one attempt only):
  with    reorder 132 seconds
  without reorder 183 seconds
- Adjust two "check" statements within func_misc.test
  which were incorrect (We had one run with result set
  difference though the server worked good.)
- minor fixes in comments

Upmerge of fix for this bug and a second similar problem
found during experimenting.

This replaces the first fix (already pushed to 5.1
and merged to 6.0) which
- failed in runs with the embedded server
- cannot be ported back to 5.0

Fix for this bug and a second similar problem
found during experimenting.

This replaces the first fix (already pushed to 5.1
and merged to 6.0) which
- failed in runs with the embedded server
- cannot be ported back to 5.0

Thanks to Paul for preparing the up-to-date files
reflecting 4.1 changes.

Bug#36724 - Test funcs_1.<engine>_storedproc_02 needs to be updated
Bug#36726 - Test funcs_1.<engine>_storedproc failing - Needs to be updated on 5.1+

func_view bug:  re-records .result files to account for addition of charset and collation data 
                to SHOW CREATE VIEW output
storedproc bugs:  Added expected errors for those storedprocs that use SQLSTATE:00000
                  in their handlers.  re-recorded .result files to account for these
                  expected errors.

There was a typo in a error check causing wrong thing to be ckecked 
and a possible error not being caught.
Fixed by using the correct variable to test for malloc() errors. 

rpl_slave_status failed on pushbuild. The slave stopped with an
error. Adding sync_slave_with_master fixes the problem. Updated
test case. 

   Bug#36345 Test 'func_misc' fails on RHAS3 x86_64
and a second similar problem within this test found
during experimenting.

  
The Diagnostic_area caused an assertion failure in debug mode when
the disk was full.
  
By setting the internal error handler to ignore errors caused by
underlying logging methods, the error is avoided.

The failing test case is depending on unnecessary status variable output
which changes based on build configuration. By reducing the output the test
becomes more stable.

and table DDL changed after PREPARE" to pass in embedded mode.

the local tree contains a fix for 
Bug#32748 "Inconsistent handling of assignments to 
general_log_file/slow_query_log_file",
which changes output of a number of tests.

after PREPARE"
Update test results after a merge with the main tree: the new minimum for 
the table definition cache is 256.

 PREPARE", review fixes:
- make the patch follow the specification of WL#4166 and remove  
the new error that was originally introduced.
Now the client never gets an error from reprepare, unless it failed.
I.e. even if the statement at hand returns a completely different
result set, this is not considered a server error.
The C API library, that can not handle this situation, was modified to
return a client error.
Added additional test coverage.

The test is vulnerable because it does not check if slave has stopped at time
of the new session is requested `start slave;'

Fixed with deploying explicitly wait_for_slave_to_stop synchronization macro.

into  bodhi.(none):/opt/local/work/mysql-5.1-27430

into  bodhi.(none):/opt/local/work/mysql-5.1-27430

PREPARE": rename members, methods, classes to follow the spec 
(a code review request)

Add test target to the makefile that will cause all
statements to be re-prepared before execution.

into  mysql.com:/d2/hf/mysql-5.1-bugteam

  rpl_innodb_bug28430 disabled

into  host.loc:/work/bk/5.1-bugteam