of untouched rows in full table scans".

SELECT ... FOR UPDATE/LOCK IN SHARE MODE statements as well as
UPDATE/DELETE statements which were executed using full table
scan were not releasing locks on rows which didn't satisfy
WHERE condition.
This bug surfaced in 5.0 and affected NDB tables. (InnoDB tables
intentionally don't support such unlocking in default mode).

This problem occured because code implementing join didn't call
handler::unlock_row() for rows which didn't satisfy part of condition
attached to this particular table/level of nested loop. So we solve
the problem adding this call.
Note that we already had this call in place in 4.1 but it was lost
(actually not quite correctly placed) when we have introduced nested 
joins.

Also note that additional QA should be requested once this patch is
pushed as interaction between handler::unlock_row() and many recent
MySQL features such as subqueries, unions, views is not tested enough.


mysql-test/r/ndb_lock.result:
  Enabled back part of the test that covers bug #20390 "SELECT FOR
  UPDATE does not release locks of untouched rows in full table scans".
  Adjusted test in such way that it now covers both execution paths
  in which we unlock non-matching rows inspected during table scan.
mysql-test/t/ndb_lock.test:
  Enabled back part of the test that covers bug #20390 "SELECT FOR
  UPDATE does not release locks of untouched rows in full table scans".
  Adjusted test in such way that it now covers both execution paths
  in which we unlock non-matching rows inspected during table scan.
sql/sql_select.cc:
  evaluate_join_record() should call handler::unlock_row() for records
  which don't satisfy condition which was pushed-down to this table/level
  of nested loop.
  We just put back the thing that we already have in 4.1 and which was lost
  when we have introduced nested joins.