Update the lib to include polling on the pwqrfd.

Update the lib to include polling on the pwqrfd.

This introduces an overcommit_count.  This counter is set by a poller
thread (or an event loop, see pwqr_overcommit_poll_loop.

On the other side, normal jobs consumers check this counter, when non 0
they XCHG it with 0 (to be sure they are alone evaluating the overcommit
ratio), ask the kernel for the current overcommit, substract one, put it
as the new counter and go to be parked.

Of course when going to be parked the threads may actually find overcommit
jobs or similar, then the polling thread will reset the overcommit_count
again in that case and this will start again. In the more common case, the
thread will be parked directly and we hope it'll be enough.

When a thread goes out of PARK mode without signaling an EDQUOT condition,
we forcefully set the overcommit_count to zero.

This should hopefully take care of the downsizing of the pool in case of
overcommit for too long. As a side note, the kernel only signals
overcommit when it's lasting for more than PWQR_OC_DELAY (which is 1/20 of
a second as of this commit), which lets plenty of time for the overcommit
to be reduced in other more "natural" ways.

Signed-off-by: Pierre Habouzit <pierre.habouzit@intersec.com>