No testcase (concurrency, tested by pushbuild2).

storage/maria/ha_maria.cc:
  a comment about what Sanja had discovered a while ago
storage/maria/ma_bitmap.c:
  guard against concurrent flush of bitmap by checkpoint: we must have close_lock here
storage/maria/ma_blockrec.c:
  comment fixed for new behaviour
storage/maria/ma_checkpoint.c:
  Release intern_lock before flushing bitmap, or it deadlocks with allocate_and_write_block_record()
  when that function needs to increase the data file's length (that function makes bitmap non flushable,
  then wants intern_lock to increase data_file_length).
  The checkpoint section which looks at the share's content (bitmap, state) needs to be protected from the possible
  my_free-ing done by a concurrent maria_close(); intern_lock is not enough as
  both maria_close() and checkpoint now have to release it in the middle.
  So the protection is done with close_lock. in_checkpoint is now protected by close_lock
  in places where it was protected by intern_lock.
storage/maria/ma_close.c:
  hold close_lock in maria_close() from start to end, to guard against checkpoint trying to flush
  bitmap while we have my_free'd its structures, for example. intern_lock was not enough as
  both maria_close() and checkpoint have to release it in the middle, to avoid deadlocks.
storage/maria/ma_open.c:
  initialize new mutex
storage/maria/ma_recovery.c:
  a comment about what Sanja had discovered a while ago
storage/maria/maria_def.h:
  comment.
  new mutex protecting the close of a MARIA_SHARE, from _start_ to _end_ of it.