default values of the tapebridged daemon.  This decision has been made because
the tape-server software has not been upgraded for a relatively long period of
time and tape opertions would like to be able to upgrade to 2.1.13-0 in two
distinct steps.  In the first step they wish to simply upgrade the daemon
executables and libraries without changing any configuration parameters.  In
the second step they wish to explicitly control the setting and using of the
new bulk configuration parameters.

bug #95975: RFE: tapebridged should gracefully shutdown the rtcpd session when get next file for recall returns an error

Following the workflow of test-driven development this is the commit of the
unit test that will fail until this RFE is implemented.

Please note that the implementation of this RFE is not planned for the
2.1.13-0 release.  Therefore the failure of this unit test which is named as
follows should simply be ignored by developers running the CPPUnit testsuite:

    castor::tape::tapebridge::BridgeProtocolEngineTest::testNoMoreRecallsDueToErrorFromTapegatewayUsingLocalDomain

we were attempting to always create missing segments even when not necessary.

Fixed creation of missing segments.

Many cosmetic changes. Changed error handling when creating missing segments on recall: if no tape routing exists, the recall is not failed but an ALERT message is logged for the missing route

Fixed reset of CastorFile when it is detected to be overwritten in the namespace. The current implementation is tested for recall case but should be reviewed before wide usage (notably at file opening time)

Fixed issue with the double meaning of the answered flag of Subrequest. As it is also used for knowing whether the subrequest should be archived, we need to reset it when restarting a recall request after a file was overwritten. Otherwise, the request is archived before the recall is actually performed, which then makes it fail

dropped useless status NEW for RecallJobs. This also fixes the issue that new recall jobs could not be handled on the fly by a running recallMount

Fixed retry of failing recalls when no destination filesystem is found. They were looping as retryOrFailRecall was not called and on top, they were retried to fast. Now they are retried only after the other files have been also tried

Reverted the autonomous transaction endTapeSession and created a specific call as the AT version created deadlocks when used in the context of the vdqmRequestsChecker. The autonomous version is used in Tape Mount liker thread.

Fixed creation of recall mounts so that we do not try to mount twice the same tape or mount unused tape

A tape coming back for a new migration mount could still be referenced in theprevious migration mount. This is due to the fact that the tape is free first in VMGR, before closing the session in the stager. This case is covered by checking for presence of such sessions, and closing them before referencing again the tape in the stager.

in our dev setups concerning the /srv/castor/tape mount.

to using the fileSystem rate. It is believed that the feedback
loop behind the fileSystem rate is too slow to be effective, and
at least on sufficiently large pools the random selection is able
to spread the recalls while the rate ordering creates hot spots.

Fixed tg_setBulkFileMigrationResult so that the two copies of one file don't go on the same tape. This was reintroduced with the bulk interface

communication logic between the Stager and the Nameserver DBs
fully explicit.