In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced
subject table didn't see the results of operation which caused invocation
of those triggers. In other words AFTER trigger invoked as result of update
(or deletion) of particular row saw version of this row before update (or
deletion).

The problem occured because NDB handler in those cases postponed actual
update/delete operations to be able to perform them later as one batch.

This fix solves the problem by disabling this optimization for particular
operation if subject table has AFTER trigger for this operation defined.
To achieve this we introduce two new flags for handler::extra() method:
HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH.
These are called if there exists AFTER DELETE/UPDATE triggers during a
statement that potentially can generate calls to delete_row()/update_row().
This includes multi_delete/multi_update statements as well as insert statements
that do delete/update as part of an ON DUPLICATE statement.

bug #26225  Engine condition pushdown doesn't work with prepare statements (ps_7ndb): ensure that query plan for prepared statement is analyzed correctly

  bug#25821  Excessive partition pruning for multi-range index scan in NDB API: added multi_range error checking in end_of_bound
ha_ndbcluster.h:
  Removed stray mthod declaration

bug#25821  Excessive partition pruning for multi-range index scan in NDB API: post-review fix, added default value

Fix for bug#25821  Excessive partition pruning for multi-range index scan in NDB API: don't set distribution key if multi_range

Bug #25522  Update with IN syntax Clustertable + Trigger leads to mysqld segfault: moved back assignment

Bug #25522  Update with IN syntax Clustertable + Trigger leads to mysqld segfault: in start_stmt, only change query_state if starting a new transactions, in read_multi_range_next, change query state when end is reached

bug#24820  CREATE INDEX ....USING HASH on NDB table creates ordered index, not HASH index: Changed test since error mesage wasn't predictable

bug#24820  CREATE INDEX ....USING HASH on NDB table creates ordered index, not HASH index: Added error checking

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

bug#18487  UPDATE IGNORE not supported for unique constraint violation of non-primary key: only check pk if it is updated

bug#18487  UPDATE IGNORE not supported for unique constraint violation of non-primary key: handle INSERT ... ON DUPLICATE KEY UPDATE

#18487  UPDATE IGNORE not supported for unique constraint violation of non-primary key: call peek_index_rows

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

bug#21507 I can't create a unique hash index in NDB: Added possibillity to create hash only indexes with NULL valued attributes, but any NULL valued access will become full table scan with pushed condition on index attribute values

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  bug#21052

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

  remove timeing dependant part of test

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  Still leakage, make sure all unlinked operations are put back so they will be release
  (on failing blob operations, when AO_IgnoreError)

into  orca.ndb.mysql.com:/export/home/space/pekka/ndb/version/my50-ndb

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

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

Bug #21072  Duplicate key error in NDB references wrong key: Re-wrote string usage to avoid valgrind warnings

into  ymer.(none):/usr/local/mysql/mysql-5.0-ndb

bugs.

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb