Partially implemented.

The Catalogue::getTapePools() method called by the CTA front-end
now returns an std::list of TapePool structures, where each
structure now has the following additional "summary"
member-variables:

  /**
   * The total number of tapes in the pool.
   */
  uint64_t nbTapes;

  /**
   * The total capacity of all the tapes in the pool in gigabytes
   * (10^9 bytes).
   */
  uint64_t capacityGigabytes;

  /**
   * The total amount of compressed data written to all the tapes
   * in the pool in gigabytes * (10^9 bytes).
   */
  uint64_t dataGigabytes;

These three additional member-variables can now be used by the
CTA front-end to provide the summary information requested by
issue #136 in the appropriate format / presentation.  For example,
the CTA front-end could subtract dataGigabytes from
capacityGigabytes in order to calculate the approximate amount of
free space.  Please note that this calculation could potentially
result in a negative number due to the fact that capacityGigabytes
is an approximate number entered by a tape operator for each tape
when they register those tapes into CTA.  In such a case the CTA
front-end should display 0 and not the negative result.

Moved TapePool from common::dataStructures:: to catalogue:: because it belongs to the Catalogue interface

Replaced set_target_properties( .. .. INSTALL_RPATH ..) with set_property (TARGET .. APPEND PROPERTY INSTALL_RPATH ..)

If the whole contents of the ARCHIVE_FILE and TAPE_FILE tables are
listed without a search criteria and with an ORDER BY clause then the
first row back from the database will take a relatively long period of
time to be returned.  This is because the database will have to sort
every row before returning the first.  This long period of time will
cause the current (non SSI) cta command-line tool to time out.

Without this index we got errors like:

[root@p06253947b39467 ~]# cta af ls --instance cta --path /eos/dev/test/gcancio/10072017/file_2167
Failed to execute the command. Reason: Failed to open root://10.16.135.81:10955//Y3Rh&YWY=&bHM=&LS1pbnN0YW5jZQ==&Y3Rh&LS1wYXRo&L2Vvcy9kZXYvdGVzdC9nY2FuY2lvLzEwMDcyMDE3L2ZpbGVfMjE2Nw==: [ERROR] Operation expired
[root@p06253947b39467 ~]#

With this index we execute the same query in less than a second:

[root@p06253947b39467 ~]# time cta af ls --instance cta --path /eos/dev/test/gcancio/10072017/file_2167
 289440       1  I20170    1381    51096      cta   18965         1006       ADLER32     0XFBA23F1D    german_raw  gcancio       c3    1499697578 /eos/dev/test/gcancio/10072017/file_2167

real    0m0.590s
user    0m0.005s
sys    0m0.006s
[root@p06253947b39467 ~]#

The reponse rate of the CTA catalogue to "eos rm"
commands was too slow.  The response rate was
around 20Hz when using the CTA/EOS production
database configured with 10 database connections.
The rate has now been increased to 30Hz by adding
the TAPE_FILE_ARCHIVE_FILE_ID_FK index.

This reverts commit 3b1855a8.

The 'SELECT FOR UPDATE' was not the bottle neck.  I am putting it
back for now.

Done.

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

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.

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.

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.

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"