Improve locking iterator performance

[dutow]

Issue: locking iterator is several times slower than the default
iterator in queries based on secondary keys.

For example:

select COUNT(*) from sbtest1 where k % 10 = 1 for update;

This query ends up iterating over the entire table, and in the end locks
the entire table, but does so by lots of small locks and seeks every
time.

This diff shows that by simply locking the entire table instead we can
improve the performance of the iterator by 50% - it's still slower than
the default implementation, but now it's much closer to it.

This modification of course results in overlocking in queries such as

select COUNT(*) from sbtest1 where k % 10 = 1 for update limit 3000;

where instead of locking only a few thousands records, with this change
we lock the entire table instead.

This change is in this form a proof of concept, for a real patch I
think we could go in two directions:

• instead of a hard coded value, make this an adjustable session
  variable
• or instead of simply stopping after a threshold, continue locking in
  linear or exponential batches

[hermanlee]

This variable needs to be initialized to 0. Otherwise, it causes random failures when m_self_lock_count > max_lock_count.

[dutow]

You are right, I missed that when I extracted this patch from a larger changeset and then I only tested it in a debug build after that. I'll fix it.

[dutow]

@hermanlee what are your thought on the two possible improvements I mentioned earlier?

(I also tested it with TokuDB, and that seems to work just like this patch: if there's some more complex query based on a secondary key, it simply locks the entire table)