Changed the default behavior of DummyCatalogue so unit tests keep passing.
Adapted SchedulerDatabase API.

Added tapepool information from the catalog in
Scheduler::getQueuesAndMountSummaries.

Created a unit test for RetrieveRequest garbage collection.
Created a RetrieveQueue::addJobIfNecessary function.
Fixed various bugs in RetrieveRequest::garbageCollect.
Added basic functionnality to DummyCatalogue for GC unit tests.
Cleaned up interace of RetrieveRequest for functions that are never used.
Implemented missing function in RootEntry.
Homogenized capitalisation of object names.
Added support for RetrieveRequest in cta-objectstore-collect-orphaned-object.

Added a tape queue and status cache update function in objectstore::Helpers.

In order to be efficient, the data (tape status and queue sizes) is cached in memory.
This function needed access to the catalogue (where the tape status is located).
This in turn required passing the catalogue object to:
 - The garbage colletion functions for all object types.
 - The garbage collector object now keeps a reference to the catalogue.
 - The path to the catalogue credential file should now be passed to cta-objectstore-collect-orphaned-object
 - The OStoreDB also needs a reference to the catalogue in order to queue retrive requests.

 The garbage collection member function are now also being passed a log context, so the requirement for better
 log of object fate can also be fulfilled later. This in turn required the passing of a logger object to
 the object store and relative helper classes.

 Finally, a dummy catalogue class has been created to be used in unit tests.

sort out tests that failed because of EOS instance

updating EOS to 4.1.25-20170717140631git057a3ea, versionlocking all the packages from the official repo as some disappeared (eos-4.1.25... is no more).

This commit does two things.  Firstly it puts back the call from:

    XrdCtaFile::xCom_deletearchive()

to:

    Scheduler::deleteArchive()

Secondly it moves the reponsibility of logging the
"Archive File Deleted" message from the CTA front-end (XrdCtaFile)
to the CTA catalogue.

Please note that Scheduler::deleteArchive() still does not call
SchedulerDatabase::deleteArchiveRequest().

This is a TEMPORARY modification to the  CTA front end.

When an "eos rm" command is executed the xCom_deletearchive()
method of the CTA front is called.  Before this commit the
mthod would try to removed the archive file from both the
object store and the CTA catalogue.  This took more than 15
seconds to complete under som ecircumstances.  This commit
removes the call to the object store.

Please note that this commit will causes a leak in archive
files.  If a file is "in-flight" and therefore has not yet
been written to tape and recorded in the CTA catalogue
then a call to "eos rm" will do nothing and the file will
eventually appear in the CTA catalogue when it is written
to tape.  The file will therefore NOT be in the EOS
namespace but it WILL be in the CTA catalogue.

This lead to a lapse moment when a mount was not wisible, and other drives tried
to mount the busy tape.

sessions.

Related to 6824973c but now it will
calculate the speed between two updates and not an average tape session
speed.

threads.

Fill creationLog for archive and retrive requests in the frontend
with actual data.

Scheduler will use real data for the requests creation time.

drive.
Change frontend reporting for the current stats from bytes to Mbytes and
from bytes/s to Mbytes/s.

If the "cta af ls" command is executed and the listing
encounters duplicate tape copy numbers then the listing
continues with "workaround" number displayed in place
of the duplicates and inow with this commit a log
message is alseo written to

    /var/log/cta/cta-frontent.log

An example log:

2017-07-12T18:04:40.691236+02:00 itdssbuild01 cta-frontend: LVL="Warn" PID="9423" TID="9436" MSG="Found a duplicate tape copy number when listing archive files" archiveFileID="5" duplicateCopyNb="1" workaroundCopyNb="2" vid="V41001" fSeq="5" blockId="41"

recall tape transfer session.

TaskWatchDog pereodically update Object store information with
current values for the tape session stats.

If the drive is set to force down mode, we stop finding new jobs and let the current session drain.

The typo made Vlado's eyes bleed.

This will help diagnose failure to honor maxDrivesAllowed.

The queue is now fully event driven: a write to object store will start as soon as the previous one completed (if any).
The notion of timeout and max number of elements before flush has been removed. This harmonises the mechanism with the
one used in MemArchiveQueue::sharedAddToArchiveQueue() (see a591129c).