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.

Fixed more slashes in paramter names (MB/s replaced by MBps) and put all tape server stats in MB (as opposed to Mib).

Created a unit test for validating the propagation of end of tape if the error happens during a flush.
Updated the FakeDrive to generate the error.
Added support for the propagation of ENOSPC error when it happens durring a flush.
Added support for end of session status recording by the FakeClient and checks in the related unit tests.

and dropped variables like _VSN in parameters.

Improved the FakeDrive so it accounts for tape space.
Improved the ClientSimulator so errors are recorded.
Improved error management in TapeWriteTask, so that ENOSPC (and only it) is propagated to the client.

with new IBM drives.

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.

Also removed slashes from parameter names.

Removed stagerjob, the stager job service and the related infrastructure, now replaced by transfermanagerd/diskmanagerd and their RPyC methods

Reviewed and fixed the error handling for migrations.
A deadlock was created by the competing usage of a stop variable an normal information flow
through the threads. The global variable's usage has been reduced and clarified:
it is set by the tape thread to indicated an error reached it. From that point
on, the remaining disk threads can stop what they are doing (and not before as failing
to read a file should not block the completion of previous ones).
The file errors are now transmitted to the client before end of session, and in case of flush.
The unit tests have been updated accordingly.
Report messages have been improved.

Added systematic logging at the end of the tape thread with the same layout for read and write, for easy tape log parsing.
Separated implementation for TapeReadSingleThread in a cpp file.

Conflicts:
	rtcopy/rtcpd_Disk.c

Fixed by only appending "?transfertype=tape" to a filename when it
is remote.

Revert "CASTOR-4624: RFIO client library incorrectly processes local URLS of the form host:path?transfertype=tape"

This reverts commit 5e89dcb2.

The bug report CASTOR-4624 is INVALID.  If implemented the solution
would break backwards compatibility with RFIO clients.  End users
should be able to create local files contain the '?' character.

In a convoluted way this commit fixes the following Savannah bug
that I could not find in JIRA:

    bug #105122: RFE: Add -f option to taped

This reverts commit 7a307cad.

This reverts commit efc1f045.

CASTOR-4624: RFIO client library incorrectly processes local URLS of the form host:path?transfertype=tape

Fixed

Fixed.

Fixed base for the connectionpool exceptions so that they do not clash with diskmanagerd and transfermanagerd ones