Backported my_atomic from 6.0-codebase and added support for 64-bit atomics to enable removal of LOCK_thread_count from every query, removed LOCK_thread_count from use in dispatch_command and close of query which is used in every query, now uses atomic increments/decrements instead

Moved atomics from 6.0 codebase to prepare for using atomic increments in places where LOCK_thread_count previously was used

into "trunk-build".

Applying fix from Oracle (Marko) for Bug #46657 "InnoDB plugin: invalid read in index_merge_innodb test (Valgrind)"

in lock_table_remove_low on INSERT SELECT) to mysql-trunk.

This is a partial correction to the original fix for bug#37098
   Get rid of "Installed (but unpackaged)" files in the RPM build
which used a wrong variable.

Updating test for smaller InnoDB buffer pool size used by the testsuite.

fix is to run the testsuite with the same InnoDB options (buffer pool size,
log file size etc) as we always ran it for the InnoDB builtin in 5.1.

Changes to ha_innodb.cc are not propagated to plugin, they will come back
via Oracle/Innobase if needed.

until it's fixed in a parent tree

Putting back Summit defaults (removing them didn't seem to have a good effect on pushbuild2).

widely used, in replication (delete_allow_opened) and for named
pipe support. We do not support Win9x anymore.

to fix test failures on OS X PPC and Sparc64

The problem is that the lexer could inadvertently skip over the
end of a query being parsed if it encountered a malformed multibyte
character. A specially crated query string could cause the lexer
to jump up to six bytes past the end of the query buffer. Another
problem was that the laxer could use unfiltered user input as
a signed array index for the parser maps (having upper and lower
bounds 0 and 256 respectively).

The solution is to ensure that the lexer only skips over well-formed
multibyte characters and that the index value of the parser maps
is always a unsigned value.

Fixes to tests and their results, to account for differences between InnoDB 1.0.4 and the old builtin.
All committed result differences have either been verified by me or copied from Oracle's provided
results (storage/innodb_plugin/mysql-test/*.result, storage/innodb_plugin/mysql-test/patches).

Problem 1:
When the 'Using index' optimization is used, the optimizer may still - after
cost-based optimization - decide to use another index in order to avoid using
a temporary table. But when this happens, the flag to the storage engine to 
read index only (not table) was still set. Fixed by resetting the flag in the 
storage engine and TABLE structure in the above scenario, unless the new index
allows for the same optimization.
Problem 2:
When a 'ref' access method was employed by cost-based optimizer, (when the column
is non-NULLable), it was assumed that it needed no initialization if 'quick' access
methods (since they are based on range scan). When ORDER BY optimization overrides 
the decision, however, it expects to have this initialized and hence crashes. 
Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 
'ref' access. 

layout as we always had in trees containing only the builtin
2) win\configure.js WITH_INNOBASE_STORAGE_ENGINE still works.

- Remove offensive quotes.

                    column on partitioned table
      
      
An assertion 'ASSERT_COULUMN_MARKED_FOR_READ' is failed if the query 
is executed with index containing double column on partitioned table.
The problem is that assertion expects all the fields which are read,
to be in the read_set.
      
In this query only the field 'a' is in the readset as the tables in
the query are joined by the field 'a' and so the assertion fails 
expecting other field 'b'.
      
Since the function cmp() is just comparison of two parameters passed, 
the assertion is not required.
      
Fixed by removing the assertion in the double fields comparision
function and also fixed the index initialization to do ordered
index scan with RW LOCK which ensures all the fields from a key are in
the read_set.
 

Note: this bug is not reproducible with other datatypes because the
      assertion doesn't exist in comparision function for other 
      datatypes.

The server shutdown and start code triggered the valgrind failures 
within nptl_pthread_exit_hack_handler on Ubuntu 9.04, x86 (but not amd64) 
in rpl_trigger.test file.

For fixing the bug, suppress valgrind failures within nptl_pthread_exit_hack_handler 
on Ubuntu 9.04, x86 (but not amd64). Because the server shutdown and start
code has been heavily used in mysql test set.