srm: refactor SchedulerFactory

This patch modifies SchedulerFactory so it has a single concern:
creating Scheduler instances.  The current implementation of
SchedulerFactory has two other concerns: creating all necessary
schedulers and maintaining a collection of schedulers. These
additional activities are moved elsewhere.

Creating all necessary schedulers has moved to the SRM class.
Ultimately this should go into the spring XML file, but I didn't want
to do too much in one patch.

Most of the behaviour associated with multiple schedules has moved
into the new SchedulerContainer class and the process of submitting a
Job to a scheduler is achieved via this new class.

One design goal is that SchedulerContainer should not 'leak' Scheduler
instances.  The getScheduler-like methods has been removed: both from
SchedulerContainer/SchedulerFactory and from SRM class.  Activity that
iterates over all the Schedulers has moved to SchedulerContainer.
Activity that targets a specific scheduler is implemented with a
method that accepts a Class<? extends Job> argument to target a
specific Scheduler.

Note that the current code has the Job classes being responsible for
adding themselves to a scheduler.  To try to keep the patch short,
this mode of operation is maintained; however, Job is supplied with a
Scheduler rather than discovering the scheduler itself.

The handler classes must be able to add a Job to a scheduler.  The
patch achieves this via the SRM object passed to the handler's
constructor.  Future patch may refactor this so the object to which a
Job is submitted is supplied on the constructor.

Another future direction is to make Scheduler an interface that the
current Scheduler class implements.  The SchedulerContainer would also
implement this interface and the similarity between SchedulerContainer
and Scheduler becomes clearer.

Another beneficial side-effect from this patch is that
SchedulerFactory is no longer a singleton.

Target: master
Requires-book: no
Requires-notes: no
Patch: http://rb.dcache.org/r/6321/
Acked-by: Gerd Behrmann
ftp: Refactor command queue into sequential executor

The FTP door uses a custom CommandQueue to provide the
ability to sequentially process commands using a shared
thread pool. This patch refactors this code into a more
generic SequntialExecutor class. It implements the
ExecutorService interface and is semantically similar to
a single thread executor. However the thread used for
processing tasks is allocated on demands from a shared
Executor.

The selective enabling of interrupts has been removed
from the FTP door. This was a workaround for bad exception
handling in old versions of the door. The workaround is
not easily ported to SequentialExecutor and is therefore
removed.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/6325/
srm: fix Copy scheduling

Recent refactoring resulted in srmCopy operations failing with the message:

    Scheduler for class class org.dcache.srm.request.CopyRequest is not
    supported.

This patch fixes srmCopy and the error message.

Target: master
Requires-book: no
Requires-notes: no
common: simplify gauge logic

removed useless if statement

Acked-by: Gerd Behrmann
Acked-by: Karsten Schwank
Target: master
Require-book: no
Require-notes: no