The previous two patches for this bug worked together so that
no permanent table was memory mapped. The first patch tried to
avoid mapping while a table is in use. It allowed mapping only
if there was exactly one lock on the table, assuming that the
calling thread owned it. During mi_open(), a different call to
memory mapping was coded, which did not have this limitation.

The second patch tried to remove the code duplication and just
called mi_extra() from mi_open() an thus inherited the limitation.
But on open, a thread does not have a lock on the table...

A possible solution would be to check for zero or one lock.
But since I learned that it is safe to memory map a file while
normal file I/O is done on it, I removed the restriction altogether
and allow to memory map while a table is in use.

No test case. I do not see a chance to verify with the test suite
which kind of I/O is used on a table.