GitLab

Replaced castor file header with CTA file header

Moved castor::server::
  BlockingQueue
  Semaphores
  AtomicCounter
  AtomicFlag
into cta::threading::

Ported DataTransferSessionTest unit test  DataTransferSessionGooddayMigration and DataTransferSessionEmptyOnVolReq.

Renamed CTA/tapeserver/castor to CTA/tapeserver/castor_checkout in preparation for the moving the sub-directory CTA/tapeserver/castor/castor up the directory tree

We had a session ending mechanism for the tape and disk tasks in migrations, but it did not cover all the aspects of the tape thread (like in this ticket, mounting). In this case the disk thread was happily reading the data from disk, which the tape thread was putting to the bin.

The signalling mechanism, attached to the task injector has now been passed to tape write thread itself, which signals the error condition when receiving any exception. If this came from a task as before, this is a no-op, but if we had a problem mounting, then the session will and immediately and disk threads will stop reading (also immediately).

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.

Refactor the code dedicated to the computation to the first fseq to writte/last fseq written on tape

No answer = end of session

This situation boils down to an empty mount, and should not put the drive down.
Also renamed a few variables so that recall and migrations use similar names.

Because it was never set up mcorrectly and hard coded to zero

Split the memory managers into headers and implementation.
Cut the number of includes by forward declaring classes.

Added a bunch of comments for MigrationTaskInjector,MigrationReportPacker, RecallTaskInjector and DataFifo

Removed interface classes DiskReadTaskInterface, DiskWriteTaskInterface, DiskThreadPoolInterface

the bytes/files numbers are specified at construction time and thus no longer necessary at the call

It will allow flushing of potential leftover requests at the end of as session and a controlled thread end.

If a Diskread ou TapeWrite task fails, all others stop and clean memory blocks while the task injector discards all remaining requests