fixes the following valgrind warning (when running ndb_mgm under valgrind,
or, indeed any other mgmapi program listening to events):

==23291== 190 (20 direct, 170 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 22
==23291==    at 0x401C895: operator new(unsigned) (vg_replace_malloc.c:163)
==23291==    by 0x8075300: ParserImpl::run(Parser<ParserImpl::Dummy>::Context*, Properties const**, bool volatile*) const (Parser.cpp:178)
==23291==    by 0x806D09B: Parser<ParserDummy>::parse(Parser<ParserDummy>::Context&, ParserDummy&) (Parser.hpp:219)
==23291==    by 0x80671C4: ndb_mgm_call(ndb_mgm_handle*, ParserRow<ParserDummy> const*, char const*, Properties const*) (mgmapi.cpp:355)
==23291==    by 0x806AB79: ndb_mgm_listen_event_internal(ndb_mgm_handle*, int const*, int) (mgmapi.cpp:1419)
==23291==    by 0x806AC1F: ndb_mgm_listen_event (mgmapi.cpp:1434)
==23291==    by 0x805EB5D: event_thread_run(void*) (CommandInterpreter.cpp:467)
==23291==    by 0x806F70A: ndb_thread_wrapper (NdbThread.c:68)
==23291==    by 0x4042340: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so)
==23291==    by 0x429D4ED: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)

fix the following valgrind warning when running ndb_mgm -e show (leak only in client)

==20398== 14,596 (11,936 direct, 2,660 indirect) bytes in 4 blocks are definitely lost in loss record 24 of 25
==20398==    at 0x401C4A1: malloc (vg_replace_malloc.c:149)
==20398==    by 0x80797A3: ConfigValuesFactory::create(unsigned, unsigned) (ConfigValues.cpp:309)
==20398==    by 0x8079F03: ConfigValuesFactory::expand(unsigned, unsigned) (ConfigValues.cpp:325)
==20398==    by 0x8079967: ConfigValuesFactory::put(ConfigValues::Entry const&) (ConfigValues.cpp:414)
==20398==    by 0x807A7B6: ConfigValuesFactory::unpack(void const*, unsigned) (ConfigValues.cpp:701)
==20398==    by 0x806CB9D: ConfigValuesFactory::unpack(UtilBuffer const&) (ConfigValues.hpp:252)
==20398==    by 0x8069160: ndb_mgm_get_configuration (mgmapi.cpp:1941)
==20398==    by 0x8060661: CommandInterpreter::executeShow(char*) (CommandInterpreter.cpp:1242)
==20398==    by 0x8063966: CommandInterpreter::execute_impl(char const*) (CommandInterpreter.cpp:715)
==20398==    by 0x8064040: CommandInterpreter::execute(char const*, int, int*) (CommandInterpreter.cpp:625)
==20398==    by 0x8064189: Ndb_mgmclient::execute(char const*, int, int*) (CommandInterpreter.cpp:203)
==20398==    by 0x805E56C: read_and_execute(int) (main.cpp:124)
==20398==    by 0x805E754: main (main.cpp:162)
==20398==

into  willster.(none):/home/stewart/Documents/MySQL/5.0/ndb

  
few cases not handled properly (NF occurs).

into  zim.(none):/home/brian/mysql/dep-5.0

into  may.pils.ru:/home/svoj/devel/mysql/BUG18874/mysql-5.0

Fixed by moving update_key_parts() down to be after write_index().

Fix for bug#20648 We introduce a new field method for knowing "real size", and we now in archive null unused bits of a row to null before writing. 

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-5.0

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-5.0

Problem described in this bug report affects MyISAM tables only.

Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.

This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.

fixups after review by jonas

  After merge fix

into  sunlight.local:/local_work/leak_fix

into  sunlight.local:/local_work/leak_fix

  Correct memory leak fix

into  willster.(none):/home/stewart/Documents/MySQL/5.0/bug13985

into  willster.(none):/home/stewart/Documents/MySQL/5.0/bug13985

  Memory leak fix

into  sunlight.local:/local_work/leak_fix

into  sunlight.local:/local_work/leak_fix

  Memory leak fix

now takes mbmaxlen into account when calculating max_length of new field. 

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1

 - Backport patch from 5.0

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

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

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

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1