The older styled add/remove by bulk are now sharing the access to object with heartbeat.
They should be more efficient. They are used for popping from queue and reporting jobs are done,
in the tape server.

This version of EOS has two fixes:

This version of EOS fixes the problem where stagerrm was removing
disk copies from the EOS namespace but was not removing the
physical files from the FSTs.

This version of EOS fixes the problem where the crashing of a tape
server whilst was creating a disk replica would cause the FST to
ask the MGM to completely remove the EOS file from the EOS
namespace, in other words dataloss.

This should ease the contention on the object store.

Timer should be reset after waiting to measure the call latency only. We were measuring call+wait.
Also improved lock monitoring (including missing monitoring of exclusive locks).

The typical log line is:
[eric@localhost CTA (master)]$ tail -1 /var/tmp/cta-rados-locking.log
Tue Jun  5 17:21:17 2018 totalCalls=9 averageAttempts=1 waitCount=0 minAttempts=1 maxAttempts=1 averageTotalTime=0.00149167 minTotalTime=0.001088 maxTotalTime=0.001986 averageLatency=0.00149167 minLatency=0.001088 maxLatency=0.001986 averageLatencyMultiplier=0 minLatencyMultiplier=0 maxLatencyMultiplier=0 samplingTime=21.3298

create_instance.sh was killed if it could not finish within 600 seconds, increased this timeout to 1000.

According to the documentation, this should limit the memory requirements of helgrind
from ~3GB to ~1GB per instance.
See http://valgrind.org/docs/manual/hg-manual.html#hg-manual.options

We now have live (to be executed), failed and to be reported queues.
Archive jobs have all three types, retrieve jobs do not have a to be reported
queue. The RootEntry interface interface now provides the choice between the types.
All uses are currently hardcoded to LiveJobs.

The error(s) gets recorded at failure time, and the list is printed at
job deletion time.