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.

With respect to the rdbms::OcciEnvSingleton 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::OcciConn class. Replaced std::mutex and
std::lock_guard with their helgrind friendly drop in replacements
threading::Mutex and threading::MutexLocker.

This will allow debugging this issue.

Replaced std::mutex and std::lock_guard with there helgrind
friendly drop in replacements threading::Mutex and
threading::MutexLocker.

The unlocking should only be attempted if we still hold the lock (it was unconditional).

See commit de5f707b: std::mutex does not use pthtread_mutex_destroy and
this confuses helgrind when two mutexes exist successively on the same address. This should remove spurious
false positives in CI.

Removed the "--encryptionkey" option from "cta tape add"

std::mutex does not call pthread_mutex_init and pthread_mutex_destroy. This is problematic when using helgrind.
See details in common/threading/MutexLtrace.cpp.

The usage of this user was added earlier. The user and group are created in RPM post install scripts.
For this reason, only the buildtree tests we affected (as the post-install script behavior needed
to be duplicated.

I have updated the help page of the "cta tape" command.  The page
now explains that encryption_key is either "none" or the name of the
individual key to be used.

Please note that encryption and its configuration is not for release
0 of CTA.  It is also not clear how much encryption configuration
details should be inside of the CTA catalogue.  We may for example
drop the concept of encryption_key name all together and just record
a boolean that simply indicates whether or not a tape is encrypted.

This uncovered several failures to fetch again after relocking objects in unit tests (fixed as well).

Added many conditional printouts in unit tests. Those printouts are controlled by #defines in a central file.

The cta-frontend and cta-taped rpms now create /var/log/cta