CASTOR-4749: tapeserverd must NOT treat tapegateway::NoMoreFiles as an error in response to a tapegateway::VolumeRequest

A new unit test has been created for validating that Volume request -> No More Files is not considered as an error.

The code has been changed accordingly. EndNotificationErrorReport is still considered an error.

Conflicts:
	castor/scheduler/diskmanager/activitycontrol.py

Renamed vdqm_CreateRequestForAggregator and vdqm_QueueRequestForAggregator to vdqm_CreateRequest and vdqm_QueueRequest

Conflicts:
	castor/castor.conf

Done.

Created a new unit test to try and reproduce the problem seen here. It did not.
The best explanation we have is a stuck file client. As we totally fail to read data
from the tape, it makes no sense to open a file for which we have no data. So we deferred
the file opening when the first memory block arrives from the tape thread. The outputs of the
unit test showed that the file opening has been successfully deferred.

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

CASTOR-4751: tapeserverd does not report drive as empty and does not finish client session if user does not have migration access-rights

The error situation was already generating an exception, which went all the way to the caller
of the data transfer session. It is now intercepted and the client is notified synchronously.
The session now ends successfully (the drive was not touched).

Fixed preloading of the krb5 library after it had been renamed. Unfortunately, its name is hardcoded...

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).

Done.

The getting of the data-transfer configuration parameters is now logged to /var/log/castor/tapeserverd.log

Done.

CASTOR-4798: tapeserverd should internally validate the fSeq of file being currently written to tape

Added fSeq tracking to the tapeFile::WriteSession and added the corresponding
calls in the tape write task.

Replaced an ad-hoc loop by a more standard and efficient remove-erase in castor::log::LogContext::erase