The C++ namespace castor::tape::tapeserver::drive now matches its
directory structure.

small change in comments in the castor.conf file so that 'actual comments' can be distinguished from commented entries

Fixed time in the summary line of draindiskserver -q. It used to be random, it's now the current time

added an Obsolete entry for castor-job in the 2.1.15 definition of castor-diskserver-manager package

        (the one from the final destination), we need to reconstruct the environment
        with the original opaque information from the headnode not the one which is
        now provided in the last request.

Continuation of fix.

Continuation of fix.

Thanks to Eric for working this one out.  The castor-lib-tape
currently requires the python-devel package.  This is actually an
unnecessary leftover from the migration policy work of the past
where such policies were written in python.  Following this theory
I am therefore removing the dependency on python-devel.

This reverts commit 6de7477f.

Switched to !IsOK() for Xroot error detection to follow common practice (IsError() is supposed to be equivalent). (fixed case)

Switched to !IsOK() for Xroot error detection to follow common practice (IsError() is supposed to be equivalent).

the atomic counter was probably fine. Leaving the debug level diagnostics in the DiskReadThreadPool code.

wait for the end of execution pipeline draining in all cases in MigrationTaskInjector::WorkerThread::run.
The asynchronous deleteAllTasks deleted the end-of-session signaling to the task injector, which led this
end of MigrationTaskInjector::WorkerThread::run into infinte waiting for this dropped end of session signal.

Attempted fix to the bug CASTOR-4736: Race condition in unit tests (tapeServer_DataTransferSessionMissingFilesMigration_Test)

The explicit separation between the decrement of the counter in AtomicCounter::operator-- was not enough
to prevent the deadlock, which was reproduced.

After just adding storage of the value in a variable and printout in DiskReadThreadPool::DiskReadWorkerThread::run,
the problem seemed to be gone after about one hour of loop testing.

I commit this change and push it to teamcity to get more chances of reproducing the issue (if it is still present).
If this patch solves the problem, we might be facing a misguided compiler optimisation.

Conflicts:
	ReleaseNotes
	castor/db/oracleStager.sql