concerning this issue.

All CTA catalogue configuration entities (archive route, tape,
tape pool, etc.) except for archive file and tape file are now
ordered alphabetically.

Archive files and tape files are ordered by archive ID and copy
number.  This ordering is required so that we can implement our
own application level cursor over potentionally all archived
files.  This could be well over 4 billion files.  We do not
rely on database cursors as they would most fail before we have
had enough time to list all archived files.

If in the future we require a file listing command that orders
achive files alphabeltically, then I would suggest the
cta::Catalogue class implements two separate methods.  The
first implementation would list all files in archive ID order
and would not rely on the underlying database to implement the
cursor.  iBasically whta we have today.  The second
implementation would list all files in alphabetcial order and
would rely on the underlying database to achieve this.

Simplified handling of already (or soon to be) mounted tapes.
Added support for next mounts.
Added logging of decision steps.

Added during investigation of scheduling issues.
Not used currently but will be usefull when implementing session preemption.

We now use protobuf's introspection to dump objects into JSON instead of ad-hoc code
using json-c.

The different processes of taped can now be identified as in this exemple:
[eric@localhost ~]$ ps -ax -o "pid comm cmd"  | grep /usr/bin/cta-taped
[...]
32593 cta-taped-main  /usr/bin/cta-taped -fl /cta-taped.log
32800 cta-tpd-VDSTK11 /usr/bin/cta-taped -fl /cta-taped.log
32801 cta-taped-gc    /usr/bin/cta-taped -fl /cta-taped.log

Rao branch

See merge request !2

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

With respect to the RadosStriperPool class,
replaced std::mutex and std::lock_guard by
threading::Mutex and threading::MutexLocker.

With respect to the GetOptThreadSafe class,
replaced std::mutex and std::lock_guard by
threading::Mutex and threading::MutexLocker.

Removed last use of std::mutex from the rdbms library

Added cta::threading::CondVar.

The new CondVar class is a C++ wrapper around a
pthread condition variable.

The new parameter is called: "taped MountCriteria".
It is a pair (size, bytes) and defaults to "80000000, 500".

Change RAO synchronization:
  * move all RAO operations right after mounting,
before the exection of any tape read task
  * while waiting for the tape to be mounted, the
ReacallTaskInjector fetches more tape read jobs
  * once the tape is mounted and the RecallTaskInjector
gets access to the drive performs RAO query for all queued
files
  * after performing RAO query for this files, RAO is deactivated

Signed-off-by: Cristina Moraru <cristina-gabriela.moraru@cern.ch>

As agreed by Eric and Steve, the "<priority | LOG_LOCAL3>" prefix
of non-syslog error messages has been dropped.

All sub-classes of the Logger class, excluding DummyLogger and
SysLogLogger, now prefix each log message with the same header
as CASTOR.

Please note that SysLogLogger class intentionally leaves the
creation of log message headers to rsyslog.  It is the
responsibility of the system administrator/operator to configure
rsyslog to generate the header syntax they wish including the
precision of the timestamp within the header.

I have removed the generation and formating of timestamps from
the CTA logging system.

removing CI_DEBUG_TRACE as it dumps all the certificates and secure variables on the build stdout...

With respect to the mediachanger::AcsProxy class. Replaced
std::mutex and std::lock_guard with their helgrind friendly
drop in replacements threading::Mutex and
threading::MutexLocker.

With respect to the mediachanger::ZmqContextSingleton class.
Replaced std::mutex and std::lock_guard with their helgrind
friendly drop in replacements threading::Mutex and
threading::MutexLocker.

The ZmqContextSingleton::instance() method was being called
prematurely.  This led to unit tests that don't actually
communicate over zero mq having "still reachable" memory
leak when executed in valgrind.

The report of a file being archived will now timeout after
15 seconds when trying to connect to EOS.   The previous
timeout was 8 minutes.

The 8 minute timeout was so long that the "kill a stalled
data transfer session" logic would kick in before the
timeout expired.  This killing logic would then mask
the underlying problem.

This reverts commit d88168ce

With respect to the rdbms::SqliteStmt class. Replaced
std::mutex and std::lock_guard with their helgrind friendly
drop in replacements threading::Mutex and
threading::MutexLocker.

With respect to the rdbms::SqliteConn class. Replaced
std::mutex and std::lock_guard with their helgrind friendly
drop in replacements threading::Mutex and
threading::MutexLocker.

With respect to the rdbms::OcciStmt class. Replaced
std::mutex and std::lock_guard with their helgrind friendly
drop in replacements threading::Mutex and
threading::MutexLocker.

With respect to the rdbms::OcciRset class.  Replaced
std::mutex and std::lock_guard with their helgrind friendly
drop in replacements threading::Mutex and
threading::MutexLocker.