MyRocks-Gap-Lock: Lock escalation and updates to transaction's list of owned locks

In TokuDB/PerconaFT range locking works as follows:

• Each SQL table has a global "Lock Tree" (see locktree.h,cc, class locktree) which stores all locks that are currently held by all transactions.
• Besides that, each transaction keeps a list of its own locks in each locktree
  in db_txn_struct_i(txn)->lt_map.

It is defined as follows:

struct txn_lt_key_ranges {

    toku::locktree *lt;

    toku::range_buffer *buffer;

};

...

    // maps a locktree to a buffer of key ranges that are locked.

    // it is protected by the txn_mutex, so hot indexing and a client

    // thread can concurrently operate on this txn.

    toku::omt<txn_lt_key_ranges> lt_map;

Lock escalation joins multiple locks into one in the global lock tree. Then it calls escalation callback (which points to toku_db_txn_escalate_callback()).

void toku_db_txn_escalate_callback(TXNID txnid, 

  const toku::locktree *lt, 

  const toku::range_buffer &buffer, 

  void *extra) 

The 3rd parameter of the function is a list of ranges that the transaction has locked after the escalation. toku_db_txn_escalate_callback replaces transaction's list of owned ranges with the provided list.
This way, lock escalation reduces memory usage in both the global lock table and in each transaction's list of owned locks.

One thing to care about is that lock escalation can happen in thread X, while the transaction operates in thread Y.

So, access to db_txn_struct_i(txn)->lt_map (or its equivalent) must be synchronized.