- Queueing into the RetrieveQueueToReportToRepackForFailure
- Reporting of the failed RetrieveJobs (add statistics + deletion of the failed sub requests)
Unit test associated : expandRepackRequestFailedRetrieve

These requests are queued in the RetrieveQueueToReportToRepackForFailure
Adapted the Sorter to be able to queue a RetrieveRequest from Repack into a queue identified by the RepackRequest's address

Updated the unit tests to validate the queues and requests are as expected.

Changed the reporting structures in the repack request to better handle repoting
(we will report one archive job per rearchived copy number, which is potentially
several per fSeq.

Created the getNextBatch() function for retrieve successes and partially implemented
the report function.

Also created the call in the maintenance process.

Reports can now be either "to user" or "to repack".

Renamed function to getNextRetrieveRequestToReportToRepackForSuccessBatch to match current naming convention.

The retrieve requests now carry all the information necessary to create the archive jobs.
Retrive requests carry an isRepack boolean. The distinction between repack and non-repack behaviour
is pushed as low as possible in the api (in the object store) so that client code can be more
generic. For the same reason, the
The expand repack mode (re-creation of missing tape files) is not supported yet.
Changed the represenation of copy numbers to uint32 (as this is the smalled number supported but protocol buffers).
Added ArchiveRoute::StorageClassMap and ArchiveRoute::FullMap to store archive routing in memory.
Added repack buffer base URL support, and mechanism to compute temporary copy location in disk cache.
Fixed bug in ObjectOps<>::asyncInsert();
Inplemented the path generation for repack disk storage (<BaseURL>/<VID>/<FSeq (09%d)>).

Renamed some status (#447 issue)
Harmonized the name of the Archive and Retrieve queues in the cta.proto file and made the changes in the C++ code

Documentation of the public methods of the sorter

Harmonized the copyNb type to uint32_t
Corrected a bug in RetrieveQueue::getContainerSummary() --> After insertion in the queue, the number of files and bytes added were equal to 0.

Queueing of Archive jobs now use the ContainerAlgorithms instead of the methods in the ArchiveQueue object
Created a base class (interface) that allows to add and remove object(s) from the ownership of an Agent (implementation : AgentWrapper) or from an AgentReference (implementation : AgentReference)

Queueing of Archive Jobs is done and unit tested
Queueing of Retrieve Requests is not completely done yet

Conflicts:
	scheduler/OStoreDB/OStoreDB.hpp
	scheduler/OStoreDB/OStoreDBFactory.hpp
	scheduler/OStoreDB/QueueItor.cpp
	scheduler/Scheduler.cpp

CatalogueTest now asserts new archive file identifiers are unique as opposed to strictly incrementing sequentially by 1

Woah!  Got carried away with const.  This commit Removes the const
qualifier from the ArchiveFileItor::next() method because next()
modifies the iterator.

To loop through an ArchiveFileItor:

  auto itor = catalogue.getArchiveFilesForRepackItor(vid, startFSeq);
  while(itor.hasMore()) {
    const auto archiveFile = itor.next();
    // Do something with archiveFile
  }

Started to queue the ArchiveRequest for Repack

Conflicts:
	objectstore/Agent.cpp
	objectstore/RetrieveQueueFailedAlgorithms.cpp
	objectstore/RetrieveQueueToReportAlgorithms.cpp
	objectstore/RetrieveRequest.cpp
	scheduler/OStoreDB/OStoreDB.cpp
	scheduler/OStoreDB/OStoreDB.hpp
	scheduler/OStoreDB/OStoreDBFactory.hpp
	scheduler/OStoreDB/QueueItor.cpp
	scheduler/RetrieveMount.cpp
	scheduler/Scheduler.cpp
	scheduler/SchedulerDatabase.hpp
	xroot_plugins/XrdCtaArchiveFileLs.hpp
	xroot_plugins/XrdCtaListPendingQueue.hpp
	xroot_plugins/XrdCtaTapePoolLs.hpp

It was using vid as container identifier where it should have used
tapepool.

Changed 'catch (cta::exception::Exception ex)' to 'catch (cta::exception::Exception &ex)' in order to avoid error: catching polymorphic type ‘class cta::exception::Exception’