Corrected helgrind errors by adding mutexes for multithread access to RecallReportPacker attributes.

If the disk threads are not finished after the TapeReadSingleThread finished, the status of the drive will be "DrainingToDisk"
This removed a RecallReportPacker exception when trying to release disk space reservation for backpressure

In DriveState::addDiskSpaceReservation and substractDiskSpaceReservation, use a reference to the mutable_disk_space_reservations item

upgrading to eos 4.7.0-20200221155245git994c2f1 that adds eosreports for failed transfers and fix xrootd query prepare on_tape bug

Added UNIQUE constraint on STORAGE_CLASS_NAME and removed the the UNIQUE constraint on DISK_INSTANCE_NAME and STORAGE_CLASS_NAME

Tape session finished message now tells if the tape has been mounted or not via the boolean wasTapeMounted

If the RecallTaskInjector had to do RAO query that takes too much time, the TapeReadSingleThread could start its infinite loop with no Recall task in it,
this would cause the stopping of the RecallTaskInjector. Thus, even if there are Retrieve jobs in the queue, as the RecallTaskInjector is stopped, the
TapeReadSingleThread will not be feed with Read tasks and will terminate. The remaining jobs in the queue will trigger a new mount

cta-catalogue-schema-verify ignores the migration-related tables (ERR$_TAPE_FILE and TEMP_REMOVE_CASTOR_METADATA)

Added the enty in the cta.spec.in

Added Statistics Schema + CppSchemaStatementsReader to compare the statistics database against its schema

Adapted SchemaChecker to be compatible with cta-statistics database

The frontend will log an error message in the cta-frontend.log file if the catalogue MAJOR schema version number mismatch and rethrow the exception to the XrdSsiCtaServiceProvider

Replaced CTA_CATALOGUE 'COMPLETE' STATUS to 'PRODUCTION'

cta.archivefile.max_size_gb 1000

Specifies maximum file size that the CTA Frontend will accept to queue
for archival. Defaults to 2 TB and can be configured in in increments
of 1 GB.

Revert "Scheduler getNextMount() does not return an ArchiveForRepack mount on a tape that is being repacked."

This reverts commit d6f97e34.

Scheduler getNextMount() does not return an ArchiveForRepack mount on a tape that is being repacked.

Scenario:
The operator launches a Repack Request in a tape V01001 (full)
During the expansion, he sets the full flag to false. The tape could be mounted for Archival. Worse, the tape could repack in itself !
This is not possible anymore.