s1543: add a flush thread counter
s1543: initial (broken) attempt to implement thread Queue

This doesn't work yet. It gets as far as self.cache.flushNodeQueue.put(self)
which should immediately trigger work by the worker thread. However,
it seems to get stuck at fileHandle = self.get() in the worker method
of FlushNodeQueue.
s1543: defer flushNodeQueue init until after FUSE starts

Starting the worker threads after FUSE has started make the
Queue work properly.
s1543: move write lock before submitting flush to queue

Put the lock prior to submitting the flush to the queue since
they could be waiting there a while.
s1543: The acquire/release has to be in the same thread...
s1543: counter is for threads actively flushing (workers always running)
s1543: add --max_flush_threads to mountvofs
s1543: set default maxFlushThreads=10
s1543: remove excessive debug messages
s1543: start worker threads for queue right after filesystem init

This second init method of FUSE is really where these threads should
be started.
s1543: use a more appropriate variable name to flag queued state
s1543: wait for queued/running flush threads to finish

The worry is that unmounting the filesystem may not properly
flush nodes that are sitting in the queue. This was probably not
a problem before since FUSE seems to detect running flushes
and doesn't allow you to unmount. However, it won't know
about queued flushes. The FUSE/vofs destroy method should
now block until the queue is empty.
s1543: make it possible to steal exclusive locks
s1543: acquire write lock when queued, release within worker thread

We want to acquire the writer lock as soon as a flush is queued, but
we don't release it until the worker thread has finished with it.
In order to do this, the flushNode method which runs in the worker
thread steals the lock.
s1543: acquire writer lock in right place, decrement thread counter properly
Merge remote-tracking branch 'upstream/random_access' into s1543

Conflicts:
	vos/CadcCache.py
Fix abort logic -- from NH
don't check for vos:LinkNode if we're only dealing with the local Cache
Changed the way truncate is done to avoid reading to cache after the truncate.
s1543: better default thread queue size, and raise exception if uses uninitialized