were accidentally removed during a previous rototill of this
code.  Fixes bug#27692.
  
While it can be argued we should strive to provide a 'secure by
default' installation, this happens to be the setup currently
documented in the manual as the default, so defer changes that
improve security out of the box to a co-ordinated effort later
on.
  
For now, make a note about the test databases and anonymous user
in mysql_install_db and recommend that mysql_secure_installation
be ran for users wishing to remove these defaults.

[..re-commit of previously lost change..]

cmake list are auto-generated and thus still required.  Correct fix
not yet known.

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M41/push-4.1

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  trift2.:/MySQL/M50/tmp-5.0

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-bj

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge

into  mysql.com:/home/psergey/mysql-5.0-bug30385

in get_index_for_order(), don't walk over the end of the index key parts
when matching index description and needed ordering.

into  production.mysql.com:/usersnfs/jperkin/bk/trees/50/mysql-5.0

into  production.mysql.com:/usersnfs/jperkin/bk/trees/50/mysql-5.0

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  xp64.:C:/work/mysql-5.0-build

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M41/push-4.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

into  dl145s.mysql.com:/data0/mhansson/my50-bug30234-push

  
DELETE FROM ... USING ... statements with the following type of 
ambiguous aliasing gave unexpected results:
DELETE FROM t1 AS alias USING t1, t2 AS alias WHERE t1.a = alias.a;
This query would leave table t1 intact but delete rows from t2.
Fixed by changing DELETE FROM ... USING syntax so that only alias 
references (as opposed to alias declarations) may be used in FROM.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime