Fix for BUG#39697 "Maria: hang when failing to insert due to UNIQUE (seen in pushbuild2 too)"

It was a forgotten rw_unlock(), due to the deadlock detector feature (so bug was only in 5.1-maria, not
6.0-maria).

mysql-test/suite/maria/r/maria3.result:
  result, all fine
mysql-test/suite/maria/t/maria3.test:
  Test of BUG#39697: two scenarios (transactional tables, and non-transactional table but dynamic row format so still taking the rwlock) where the hang happened.
  t2 added by this test was masked by a temporary table created earlier in the test, which we forgot to drop.
storage/maria/ha_maria.cc:
  use new macro
storage/maria/ma_blockrec.c:
  use new macro
storage/maria/ma_commit.c:
  use new macro
storage/maria/ma_init.c:
  putting address of dummy_transaction_object in --debug trace can be useful
storage/maria/ma_open.c:
  use new macro
storage/maria/ma_write.c:
  if local_lock_tree is true, we have acquired keyinfo->root_lock so need to release it before "goto err".
  A pair of assertions so that our usage of TrIDs is kept sensible.
storage/maria/maria_def.h:
  A macro so that changes of MARIA_HA::trn can be tracked with --debug. It helped to understand in what cases,
  in maria_write(), we could have !(info->dup_key_trid == info->trn->trid) && !share->now_transactional
  (answer: ALTER TABLE adding UNIQUE index on transactional table).

1 files changed, 2 insertions, 0 deletions

diff --git a/storage/maria/ma_init.c b/storage/maria/ma_init.c
index f657289ac76..1f2eddd7e30 100644
--- a/storage/maria/ma_init.c
+++ b/storage/maria/ma_init.c
@@ -68,6 +68,8 @@ int maria_init(void)
   }
   hash_init(&maria_stored_state, &my_charset_bin, 32,
             0, sizeof(LSN), 0, (hash_free_key) history_state_free, 0);
+  DBUG_PRINT("info",("dummy_transaction_object: %p",
+                     &dummy_transaction_object));
   return 0;
 }