The queue is now fully event driven: a write to object store will start as soon as the previous one completed (if any).
The notion of timeout and max number of elements before flush has been removed. This harmonises the mechanism with the
one used in MemArchiveQueue::sharedAddToArchiveQueue() (see a591129c).

This constraint prevents a tape server from writing the same file
more than once to the same tape.  We should actually allow this
to happen so that we can tolerate the pathological case of a
cta-taped daemon crashing immediately after inserting a row into
the TAPE_FILE table and before updating the object store.

Implemented GarbageCollector::reinjectOwnedObject() and called it on garbage collector shutdown.
This fixes the issue of non-empty garbage collectors exiting.

Simplifies code and avoids unnecessary string copy construction

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.