Both tapeFile::ReadSession and tapeFile::WriteSession start by
reading VOL1 by calling Drive::readBlock() with a block of 84
bytes even though Logical Block Protection (LBP) is turned off
at this early stage of a session.  With LBP turned off, a drive
will only return the exact record being read and wil not add 4
CRC bytes at the end.  This means the drive will always return
80 bytes.

Both tapeFile::ReadSession and tapeFile::WriteSessioas called
Drive::readBlock() with a block of 84 bytes in order to work
with an "in-house" version of mhvtl that tried to support LBP.
Unfortunately the behaviour of this special version of mhvtl
was incorrect because it would 84 bytes when LBP was disabled.

The "in-house" version of mhvtl trying to support LBP is no
longer used with CASTOR.  This commit therefore simplfies the
CASTOR code by replacing Drive::readBlock() with
Drive::readExactBlock and by removing the conditional logic
that dealt with the existance of an 84 byte VOL1 label in the
presence of the "in-house" version of mhvtl.

Prepare was failing in client_ar.sh because of a typo in KrB5CCNAME, adding -s to prepare as by xrootd definition we are staging files to disk and not discovering them.

moment and won't be used in production (egroups).

Must add prepare acl on /eos/ctaeos/cta folder so that the retrieve works for the first test (may not be useful...)

This reverts commit 0b25a06a

Each thread has its own rados context. The thead pool, when used will allow better
parallelism of asynchronous requests.

This required some rework on the backend creations as the threads will need logging.

This will limit contention on the scheduling lock when there is no new mount to schedule (which
is the majority of the time).