The status of the repack request is updated throughout all its lifecycle (Pending, ToExpand, Starting, Running, Complete or failed)

Replaced the map of tape files with a list as the assumption that we have one copy per copyNb is no more valid with repack.

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.

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

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 is done and unit tested
Queueing of Retrieve Requests is not completely done yet

Removed the "User" message from the cta.proto (duplication of UserIdentity message)

-> Moved code related to payload manipulation in the cta::objectstore::RetrieveRequest class

Changed the status of succeeded retrieve requests as RJS_Succeeded and inserted them to the RetrieveQueueToReportToRepackForSuccess, unit tested but memory leak

"ToTransfer" are to be picked up by tape sessions.
"ToReport" Includes both successes and failures to report, as the mechanism to report is the same.
   They will be handled by the reporter, which shares the single thread of the garbage collector.
"Failed" Will be a (possibly non-queue) container which will contain the failed requests. The operators
   will be able to examine, relaunch or abandon those requests.

The states and lifecycles of the requests have been reworked to reflect this lifecycle too.
The container algorithmes have been adapted to handle the multiple queue/container types.