WL#7260: Split LOCK_thread_count

Affects: Server-5.7   —   Status: Complete   —   Priority: Medium

LOCK_thread_count is currently (after improvements in WL#6606) a major bottleneck
when connecting/disconnecting clients. This mutex protects several independent 
structures/variables. It can therefore be split into several mutexes, each
protecting a separate structure/variable.

This should give clear performance improvements. A draft patch has shown ~50%
improvement for clients doing connect + 1 query + disconnect.

User Documentation

Changes to the interface specification:
I-1: The following status variables will no longer be visible in embedded server 
     where they never had any effect: Aborted_connects, Connection_errors_accept,
     Connection_errors_internal, Connection_errors_max_connections,
     Connection_errors_peer_address, Connection_errors_select,

No other changes to behavior (except improved performance) or interfaces.
LOCK_thread_count should be split into:
1: LOCK_thread_count - protecting the list of connections
2: LOCK_thread_cache - protecting the "thread cache" for the per-thread 
                       connection handler.
3: LOCK_thread_id    - protecting the thread_id global counter.
                       (This could be implemented with atomics rather than mutex)

Also consider if LOCK_thread_count usage in replication code could be reduced.