The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.

The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.

The ProcessForker can impose "entire lifetime" or "per mount"
refreshes of CASTOR configuration-parameters.  There is no
need for the tapeserverd parent process to do this and send
the results over the wire.

Vlado found this bug whilst running tapserverd with real tape hardware.
Mounts last long enough with real hardware for an operator to easily
use "tpconfig down" on a running drive.

The tapserverd process was not handling the WAIT_DOWN state correctly
and was throwing an unexpected exception that in turn caused the process
to crash due to the resulting abort signal.

The tapserverd process was not handling the WAIT_DOWN state correctly
due to some over simplifications I made to the architecture of
tapeserverd.

Removed redundant methods and added sessionSucceeded() and
sessionFailed() callback mechanism to DriveCatalogueSession.

Please note that this version still does not handle the bad day
scenarios of a tape label session, nor does it fully implement
the cleaner or heartbeat logic.

The DriveCatalogueEntry class was initialising the host-name/server
to be used with the vdqm to an empty string and never changing it
there after.  This of course was causing the security features of
the vdqm to reject requests from tapeserverd to change its state.

Please note that the "integration" code of tapserverd is not fully
functional.  One should however be able to run a data transfer
session.

PLEASE NOTE - The bad day tape label scenarios are broken by this
commit.  I will fix them in a future commit.