Bug #43487 Change THR_LOCK_myisam to use MY_MUTEX_INIT_FAST

Description:
Concurrent workloads for MyISAM are faster when THR_LOCK_myisam is initialized with MY_MUTEX_INIT_FAST instead of MY_MUTEX_INIT_SLOW. 

Results from:
* sysbench readonly with --oltp-secondary-index patch from me
* 16 core server using Linux 2.6 and x86_64
* numbers from 1,2,4,8,16,32, 64 concurrent sessions
* 2M rows in sbtest table

Throughput (number from transactions: line in sysbench output)
 242  499  834 1060  875  725  618 -- 5.0.75 unmodified
 247  511  841 1132  906  754  667 -- 5.0.75 with suggested change

How to repeat:
na

Suggested fix:
Get rid of MY_MUTEX_INIT_SLOW

Thank you for the bug report.

Rather a trivial fix (one line), but we need to figure out reasons for initializing THR_LOCK_myisam as slow.

I think it gets more interesting than that. You need to determine why this and other mutexes use MY_MUTEX_INIT_SLOW. One or more mutexes used for replication code in log.cc also use SLOW.

For another data point, I changed LOCK_event_loop and LOCK_thd_add to use MY_MUTEX_INIT_FAST and sysbench readonly throughput was 10% better for a 16-core server with 16 concurrent users, thread_handling=pool-of-threads and thread_pool_size=20.

The current choice of NULL, MY_MUTEX_INIT_FAST or MY_MUTEX_INIT_SLOW in pthread_mutex_init calls appears somewhat random. And if it isn't random, comments in the code sure would be nice.