incorrect key file for table

In certain cases it could happen that deleting a row could
corrupt an RTREE index.

According to Guttman's algorithm, page underflow is handled
by storing the page in a list for later re-insertion. The
keys from the stored pages have to be inserted into the
remaining pages of the same level of the tree. Hence the
level number is stored in the re-insertion list together
with the page.

In the MySQL RTree implementation the level counts from zero
at the root page, increasing numbers for levels down the tree.

If during re-insertion of the keys the tree height grows, all
level numbers become invalid. The remaining keys will be
inserted at the wrong level.

The fix is to increment the level numbers stored in the
reinsert list after a split of the root block during reinsertion.

into  bk-internal.mysql.com:/data0/bk/mysql-4.1-opt

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint

into  mysql.com:/home/hf/work/25492/my41-25492

into  mysql.com:/home/tnurnberg/24660/41-24660

ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used. Now if 0xff makes an appearance, we find a character not used in the enum and
use that as a separator. If no such character exists, we throw an error.

Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.

into  siva.hindu.god:/home/tsmith/m/bk/maint/41

into  mysql.com:/home/gluh/MySQL/Merge/4.1-opt

into  poseidon.mysql.com:/home/tomas/mysql-4.1-ndb

into  pilot.mysql.com:/home/msvensson/mysql/mysql-4.1-maint

 - strerror might return NULL on some platforms

into  pilot.mysql.com:/home/msvensson/mysql/mysql-4.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-4.1-maint

into  pilot.mysql.com:/home/msvensson/mysql/mysql-4.1-maint

 - Backport fix from 5.0

into  mysql.com:/usr/home/ram/work/bug23938/my41-bug23938

into  mysql.com:/usr/home/ram/work/bug10798/my41-bug10798

into  chilla.local:/home/mydev/mysql-4.1-axmrg

added valgrind.supp to EXTRA_SCRIPTS(for pushbuild)

into  mysql.com:/home/ram/work/b26012/b26012.4.1

As we have Field_double::not_fixed we must have Field_double::size_of().

into  dev3-63.(none):/home/zhl/mysql/tree-merge/4.1/mysql-4.1-ndb

into  chilla.local:/home/mydev/mysql-4.1-axmrg

Notes:
This patch doesn't fix all issues in the tree and we need jani's fix for that
This patch shoud not be merged into 5.0

into  chilla.local:/home/mydev/mysql-4.1-axmrg

into  chilla.local:/home/mydev/mysql-4.1-axmrg

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint

into  qualinost.(none):/home/mtaylor/src/mysql-4.1-maint

into  mysql.com:/home/svoj/devel/mysql/WL3567/mysql-4.1-engines

When a merge table is opened compare column and key definition of
underlying tables against column and key definition of merge table.

If any of underlying tables have different column/key definition
refuse to open merge table.

into  mysql.com:/home/ram/work/b19690/b19690.4.1

Depending on the queries we use different data processing methods
and can lose some data in case of double (and decimal in 4.1) fields.

The fix consists of two parts:
1. double comparison changed, now double a is equal to double b 
if (a-b) is less than 5*0.1^(1 + max(a->decimals, b->decimals)). 
For example, if a->decimals==1, b->decimals==2, a==b if (a-b)<0.005
2. if we use a temporary table, store double values there as is 
to avoid any data conversion (rounding).

Made the function opt_sum_query to return HA_ERR_KEY_NOT_FOUND when
no matches were found (instead of -1 it returned prior this patch).
This changes allow us to avoid possible conflicts with return values
from user-defined handler methods which also may return -1. 
No particular test cases are provided with this fix.