Retry once the archiveretrieve CI job, as sometimes the eos instance reports no space for a possible bad timing between the FST and the MGM.

and 1 hour by default.
Previously when cta frontend coredumped, all the files appeared to have
been successfully deleted when it was not the case.
I am now making sure cta client returned with no error to correctly
detect failures.

repository (resolution order is protected > priority > versionlock).
Adding versionlock on xrootd and others in the build process to make
sure we have the same version in build_rpm and ci runs

twice and outputs EOS workflow proc content to list various type of
errors.

pushing a bit harder in the tests with 1000 files of 15kB that should fill 1.5 tapes (100MB each in CI).

removing CI_DEBUG_TRACE as it dumps all the certificates and secure variables on the build stdout...

Add publish_tagged_rpm and needed helper derived from https://gitlab.cern.ch/ci-tools/ci-web-deployer as we need to run the update_repo.sh hook after the file transfert.

Adding cta_tagged_rpm stage. CTA_RELEASE and CTA_VERSION are not exported as is to avoid overriding environment variables used by cmake. Therefore I am using TAG_VERSION and TAG_RELEASE.

Print CTA_BUILD_ID in the jobs and not the full SHA of the commit of course. The generated rpm version was OK but the logs were useless.

`CI_BUILD_REF` environment variable has been dropped in [gitlab 9.0](https://cern.service-now.com/service-portal/view-outage.do?n=OTG0037271)

now expiring artifacts after 30 days as the repository was reaching 10GB quota limit (by the way this limit has been raised to 20GB today).