Default ctafrontend rpm xrootd configuration file is CI ready. No more duplicate in the continuousintegration tree.

Changing /etc/ctafrontend_SSS_c.keytab and /etc/ctafrontend_SSS_s.keytab to /etc/cta/cta-cli.sss.keytab so that CI and preprod have now the same configuration files.

Keep in mind thatL
The user in the ctafrontend SSS key is the EOS instance name, the rest is BS. I tried to make it clear in the configuration files and names when a field is useless.
WFE scripts are now the same between preprod and CI and the ctafrontend
configuration file can move in the rpm.

Using /etc/cta/cta-frontend.krb5.keytab file as ctafrontend kerberos keytab instead of /etc/cta-frontend.krb5.keytab

moving ctafrontend xrootd configuration file from /etc/xrootd/xrootd-cta.cfg to /etc/cta/cta-frontend-xrootd.conf

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

Fixing the fluctuations in the archived file count that are due to the automatic deletion of disk replicas in the workflow.

Conflicts:
	objectstore/BackendRados.hpp
	objectstore/BackendVFS.hpp
	objectstore/GarbageCollector.cpp
	objectstore/GenericObject.cpp

Some typo fixes.

This ensures we will not fail to grab a lock in case a process dies.

This led to garbage collactor segfaults.

This allows previously developped asyncLockfreeFetch to apply to it.

The previous strategy was made under the assumption that we needed to lock sparingly.
With the introduction of lockfree strategy, this is not true anymore.
The new strategy will be immune from the A watches B, B watches A, both die, and
no one garbage collects them situation (also called cyclers in utility cta-objectstore-unfollow-agent).