We now only do one queue update at a time (per process). While one batch is being pushed to the objet store, the
following one is being built up, and written as soon as the previous write completes. This can be see in the timings from
the logs of the unit test OStoreSchedulerDatabaseTestVFS/SchedulerDatabaseTest.createManyArchiveJobs/0 here:
[...] MSG="In MemArchiveQueue::sharedAddToArchiveQueue(): added batch of jobs to the queue." objectQueue="archiveQueue-[...]-68" sizeBefore="0" sizeAfter="1" addedJobs="1" waitTime="0.002403" enqueueTime="0.036594"
[...] MSG="In MemArchiveQueue::sharedAddToArchiveQueue(): added batch of jobs to the queue." objectQueue="archiveQueue-[...]-68" sizeBefore="1" sizeAfter="100" addedJobs="99" waitTime="0.036547" enqueueTime="0.001629"
[...] MSG="In MemArchiveQueue::sharedAddToArchiveQueue(): added batch of jobs to the queue." objectQueue="archiveQueue-[...]-174" sizeBefore="0" sizeAfter="1" addedJobs="1" waitTime="0.000058" enqueueTime="0.061447"
[...] MSG="In MemArchiveQueue::sharedAddToArchiveQueue(): added batch of jobs to the queue." objectQueue="archiveQueue-[...]-174" sizeBefore="1" sizeAfter="198" addedJobs="197" waitTime="0.061434" enqueueTime="0.001431"
[...] MSG="In MemArchiveQueue::sharedAddToArchiveQueue(): added batch of jobs to the queue." objectQueue="archiveQueue-[...]-174" sizeBefore="198" sizeAfter="200" addedJobs="2" waitTime="0.000840" enqueueTime="0.037259"

twice and outputs EOS workflow proc content to list various type of
errors.

It appeared in production that the update latency could be steadily higher than this delay.
This led to an ever growing perceived latency by the client, as the batches to be queued accumulated
faster than they were drained.

This is an interim solution to a more adaptive one which should make no asumption.

Handling of multi-block responses and streaming is not yet implemented.

Renames private member variables. Changes to some constructor arguments.

First character of XrdSsi metadata is overwritten with zero, see
https://github.com/xrootd/xrootd/issues/537
This workaround adds a dummy character to the front of the metadata on
the server side and removes it on the client side.

Added computation of files on tapes (based on last Fseq).
Fixed computation of writable tapes count.

Now waits n=30 secs for any outstanding requests to finish before
giving up and executing a forced shutdown.

Wrong parameter passing fixed.

Added tape statistics for retrieves.
Added oldest jobs age.

Fixed a typo in a variable name.

Increated the width of the size column of the result of
"cta archivefile ls" to 12 characters.  The column is in bytes
which means that we can now display a file size of just under
1 Terabyte.

those were 15kB -> 150kB will be better...

RdbmsCatalogue::reclaimTape() now resets the DATA_IN_BYTES column
of the TAPE table.

Improved unit tests to test for the fact that reclaim should
reset the tape occupancy field.

The following unit now "succesfully" fails:

[ RUN      ] InMemory/cta_catalogue_CatalogueTest.reclaimTape_full_lastFSeq_1_no_tape_files/0
/home/smurray/CTA/catalogue/CatalogueTest.cpp:7029: Failure
Value of: tape.dataOnTapeInBytes
  Actual: 1
Expected: 0
[  FAILED  ] InMemory/cta_catalogue_CatalogueTest.reclaimTape_full_lastFSeq_1_no_tape_files/0, where GetParam() = 0x7fc58e93eab0 (7 ms)

The next step is to fix the bug in reclaim.

pushing a bit harder in the tests with 1000 files of 15kB that should fill 1.5 tapes (100MB each in CI).

Enable it in the CI tests.

The ArchiveRequest was not garbage collected if had already been requeued before, as the
corresponding status was overlooked.

Created an objectstore utility for requeuing ArchiveRequests after deleting archive or retrieve queues.

This utility is to be used for cleaning up the pre-prod environement following a schema change in the archive queues.
It could support all object types on the long run, but currently only supports ArchiveRequests.

Metadata can be used for short replies (less overhead than a full reply)
or to provide information about the reply which will follow (e.g. number
of records, response size, etc.)

Alerts can be used to signal the client about the server state.