GitLab

[migration] Fixed grant following change whereby VMGR is updated by the CASTOR Nameserver as opposed to the CTA catalogue

This implementation (unfortunately) introduces one more CLI, but
it makes the 0-byte files migration fully independent from the rest.
The main reason is that the query to extract them from the CASTOR
Nameserver is pretty expensive.
The README.md file and the packaging have been updated accordingly.

Where to store the CASTOR legacy data will hopefully be decided in the future.

The VMGR tapes are now flagged as EXPORTED only at the very end,
if everything went fine, as opposed to before the EOS namespace injection.
Also there's one less PL/SQL procedure on the CTA catalogue.

This eases recovery in case of interruptions, at the cost of a larger transaction.
To be tested with the largest tape pools we have in CASTOR.

A previous commit had spun part of the code into a base library, but the split of the library was not helping.
Replaced the cta-lib-base RPM with a cta-lib-common RPM.

Corrected the CatalogueTest::getSchemaVersion() so that the schema version is compared against the CTA_CATALOGUE_SCHEMA_VERSION_MAJOR/MINOR

The catalogue.ping() method now checks the equality between the MAJOR version number of the CTA schema version and the MAJOR version number in the database

The insertion of the version of the Catalogue schema into the DB is now done when the schema sql files are generated. (catalogue/CMakeLists.txt)
The CTA_CATALOGUE_SCHEMA_VERSION_MAJOR and the CTA_CATALOGUE_SCHEMA_VERSION_MINOR are also inserted in version.hpp.in