memory leak in worker_stop()

As reported by Julien Blache:

The most recent and potentially disruptive change is the introduction of
overcommit support in pthread_workqueue, which was kind of my primary
suspect yesterday.

This is what valgrind has to say, biggest leak it finds:

==30491== 790,208 bytes in 12,347 blocks are still reachable in loss record 96 of 96
==30491== at 0x402764D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30491== by 0xC79C34D: witem_alloc (witem_cache.c:47)
==30491== by 0xC79B62B: manager_main (manager.c:383)
==30491== by 0x776BB3F: start_thread (pthread_create.c:304)
==30491== by 0x8F1936C: clone (clone.S:112)

I see roughly 264 kB per 6-7 minutes and I stopped the process after 20
minutes, so it's coherent at roughly 790 kB.

Adding some debug in witem_cache.c on allocation and release:

WQ [3042]: manager_main(): manager is sleeping
WQ [3042]: manager_main(): manager is awake
WQ [3042]: manager_main(): load=1 idle=33 workers=34 max_workers=15891 worker_min = 2
WQ [3042]: manager_main(): worker_idle_seconds_accumulated = 33, scoreboard.idle = 33, scoreboard.count = 34

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845af0

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845b40

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845b90

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845be0

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845c30

WQ [3042]: manager_main(): Removing one thread from the thread pool
WQ [3042]: witem_alloc(): allocated witem 0x845c80

Except ... idle and workers never decrease (number of threads shown by
the system remains unchanged and matches the numbers) and there never is
a corresponding

WQ [nnnn]: witem_free(): freeing witem 0x..........

that I also added to witem_free(). It also correctly appears for regular
operations:

WQ [3048]: witem_alloc(): allocated witem 0x7f5e5c044020

WQ [3048]: manager_workqueue_additem(): signaling an idle worker
WQ [3048]: pthread_workqueue_additem_np(): added an item to queue 0x7a9770
WQ [3043]: witem_free(): freeing witem 0x7f5e5c044020

So, bottom line, worker_stop() allocates a witem when stopping a worker
thread, except the thread does not actually stop and the witem doesn't
get freed either. No worker thread gets woken up after worker_stop()
queues the job.