restore: simplify SIGINT/SIGTERM/SIGUSR1 and interrupted handling

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
restore: moving pthread cancelling into restore.c from mksquashfs.c

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: implement queue_flush()

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: abstract hash table size and don't hard code it everywhere

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
caches-queues-lists: implement seq_queue_flush()

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
gzip_wrapper: fix -Xwindow-size option return value

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
restore: redo thread termination when restoring filesystem on appending

I recently reworked filesystem restoration in Mksquashfs where ^C
is hit twice when appending.  When this happens Mksquashfs has
to terminate all the threads and restore the filesystem.

Originally, when Mksquashfs was enhanced to do multi-threading
(parallelised), this was done by sending all the threads a signal
and then having them go to sleep in their signal handlers.
This was an acceptable solution, but, it suffered from the fact
threads could go to sleep holding pthread mutexes, and so workarounds
had to be added for that.  But an advantage was thread cancellation
was instantaneous.

The rework redid things to be cleaner, restoring is now done on a
special restore thread, rather than the setjmp/longjmp inherited from
the original single threaded Mksquashfs, and thread cancellation is
now done via the pthread_cancel mechanism, ensuring threads do
not go to sleep holding mutexes, allowing the workarounds to be
removed.

However, on slow computers, I have noticed an annoying tendency for
the new code to "hang" for an apppreciable time when ^C is hit
twice, without any activity apparently taking place.

The new cache/queue dump code (which is run when ^\ is hit twice, and
which can be run while Mksquashfs is restoring), neatly pin-pointed
the cause.  During thread cancellation, the decompress and
fragment decompress threads continue to run taking input from their
input queues, and delivering it to their output queues, and only
terminate when either there is no more input or there is no more
space in the output queue.

This behaviour was tracked down to the fact that the decompress and
fragment decompress threads do not ordinarily execute any code which
is a pthread cancellation point - the only call executed which is
a pthread cancellation point is pthread_cond_wait which the threads
only execute if either a queue is empty or full.

Now, this problem could be fixed by the insertion of an explicit
pthread cancellation check call (pthread_testcancel) but this
potentially slows down the most compute intensive threads in
Mksquashfs, for an eventuality (thread termination on appending
if and only if ^C is hit twice) which is very rarely going to
happen.

So the solution that has been adopted is to rework the thread
termination code to forcibly cause each thread to idle.  What this
means is thread termination is now carefully done, thread
termination is now done starting from the ultimate source thread
(the reader thread), the queues from that are flushed, causing the
"downstream" threads to idle, which are then terminated, their
output queues are flushed, causing the threads downstream from them
to idle, which are then cancelled, and so on until the ultimate
destination thread (the writer thread) is cancelled.

This results again in instantaneous thread cancellation when
^C is hit twice, irrespective of slow CPU speed or slow output
devices which may have resulted in large queues of unprocessed
buffers.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>