mksquashfs: simplify print_filename in info.c

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
mksquashfs: fix progress bar enabling/disabling

Previously I rewrote the progress bar to introduce temporary disabling
and enabling for the info thread (when it is displaying the cache/queue
status the progress bar needs to be disabled).

This commit unfortunately didn't go far enough, it left
the situation where:

1. mksquashfs at start-up enabled the overall progress bar enable
   flag (but didn't turn it on)
2. Used the call "enable_progress_bar" to turn on the progress bar, and
3. Used the call "disable_progress_bar" to disable the progress bar once
   compression had been done (prior to generating the statistics dump
   and exiting).

This was a significant improvement in that hitting ^\ twice no
longer resulted in the progress bar being enabled even if it had been
explicitly disabled on the command line, but, it has been noticed (by me)
that there were still some weird cases:

1. Hitting ^\ twice to display the cache/queue status *before* the
   progress bar was turned on by mksquashfs would prematurely enable
   the progress bar.
2. Hitting ^\ twice to display the cache/queue status *after* the
   progress bar was turned off by mksquashfs would turn the progress
   bar back on.

The reasons for this should be readily apparent:

In case 1. the enable_progress_bar() called by the info
thread to re-enable the progress bar would prematurely enable it.

In case 2. the enable_progress_bar() called by the info
thread to re-enable the progress bar would unwantedly re-enable it.

The solution of course is that the main mksquashfs thread should
never have been using the temporary calls to "hard" enable and
disable the progress bar when it wanted to turn on and turn off
the progress bar.   So update set_progressbar_state() to do the "hard"
enabling/disabling when the main mksquashfs thread wants to do it.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
progressbar: set_progressbar_state() can be called by threads killed

when restoring the filesystem, due to this we must ensure
the mutex is cleanly released.

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