Cleanup/reorder/rename for some fields.

ls' command. Fix spaces in outputs.

Converted all bytes to Mbytes. Removed extra space in the output.
Reordered fields.

This commit does two things.  Firstly it puts back the call from:

    XrdCtaFile::xCom_deletearchive()

to:

    Scheduler::deleteArchive()

Secondly it moves the reponsibility of logging the
"Archive File Deleted" message from the CTA front-end (XrdCtaFile)
to the CTA catalogue.

Please note that Scheduler::deleteArchive() still does not call
SchedulerDatabase::deleteArchiveRequest().

This is a TEMPORARY modification to the  CTA front end.

When an "eos rm" command is executed the xCom_deletearchive()
method of the CTA front is called.  Before this commit the
mthod would try to removed the archive file from both the
object store and the CTA catalogue.  This took more than 15
seconds to complete under som ecircumstances.  This commit
removes the call to the object store.

Please note that this commit will causes a leak in archive
files.  If a file is "in-flight" and therefore has not yet
been written to tape and recorded in the CTA catalogue
then a call to "eos rm" will do nothing and the file will
eventually appear in the CTA catalogue when it is written
to tape.  The file will therefore NOT be in the EOS
namespace but it WILL be in the CTA catalogue.

Fill creationLog for archive and retrive requests in the frontend
with actual data.

Scheduler will use real data for the requests creation time.

drive.
Change frontend reporting for the current stats from bytes to Mbytes and
from bytes/s to Mbytes/s.

The typo made Vlado's eyes bleed.

Added computation of files on tapes (based on last Fseq).
Fixed computation of writable tapes count.

Fixed a typo in a variable name.

First version of a streaming "cta archivefile ls" command.

Typicaly updated every few seconds.

Fixed the timings so they show up in all states.
Removed lds command.
Added error message when a drive is not found for single drive ls.

Removed the member variable XrdCtaFile::error that was incorrectly
shadowing XrdSfsFile::error.

Added the XrdCtaFile::m_listingArchiveFiles member variable and
factorized XrdCtaFile::readFromCmdlineOutput() out from
XrdCtaFile::read() so that in the future the XrdCtaFile::read()
method will be able to treat the listing of archive files
differently from other cta commands.

Currently none of the cta commands are incrementally generating
and streaming large result sets back to the cta command-line
tool.  All commands are generating the entire result in the
constructor of XrdCtaFile.  The result is streamed back to the
cta command-line tool, but the result is generated in one
single stepi before any streaming starts.

The listing of archive files is being gradually modified to
incrementaly generate the result in each call to
XrdCtaFile::read().  This commit is one step in this
larger modification.

Put back the serialising of the command return code.  This was
once done within the XrdCtaFile::getMmap() method.  It is now
done within the XrdCtaFile::logRequestAndSetCmdlineResult()
method.

Please note that command return codes must be in the range "0"
to "9" because the first ASCII character sent back from the
CTA front-end to the cta command-line tool is the return code.
The following code snippet from the implementation of the cta
command-line tool shows the format of the reply from the CTA
front-end to the cta command-line tool:

  // The cta frontend return code is the first char of the answer
  {
    uint64_t readOffset = 0;
    uint32_t bytesRead = 0;
    char rc_char = '0';
    const XrdCl::XRootDStatus readStatus = xrootFile.Read(readOffset, 1, &rc_char, bytesRead);
    if(!readStatus.IsOK()) {
      throw std::runtime_error(std::string("Failed to read first byte from ") + cmdPath + ": " +
        readStatus.ToStr());
    }
    if(bytesRead != 1) {
      throw std::runtime_error(std::string("Failed to read first byte from ") + cmdPath +
        ": Expected to read exactly 1 byte, actually read " +
        std::to_string((long long unsigned int)bytesRead) + " bytes");
    }
    rc = rc_char - '0';
  }

Removed unnecessary member variable XrdCtaFile::m_cmdlineReturnCode

Removed unused int return from logRequestAndSetCmdlineResult().

Simplified the XrdCtaFile class.  logRequestAndSetCmdlineResult()i
is now only called by XrdCtaFile::open().

Revert "Revert "cta/CTA#139 cta af ls --vid XXXXX command times out if there are many files on a tape""

This reverts commit 2ce6b867.

This reverts commit 72810551.

This revert is being made because the original commit broke the
"cta logicallibrary add" command.

The CTA front-ends code for replying to requests is currently
incompatible with streaming back large reply messages such as
the contents of a tape.

Executing the "cta" command-line tool results in the CTA
front-end creating a temporary server side representation of
a file.  The XrdCtaFile class implements this server side
representation of a file.

The constructor of the XrdCtaFile class generates the entire
contents of the file in one shot.  The contents of the file
are in fact the message a user of the "cta" command-line
eventually sees on their screen (standard out).

The entire single shot contents of the file are presented to
the XRootD framework as a memory mapped file which is in
fact a simple "one-shot" array of bytes.  This memory mapped
file approach is implemented by the XrdCtaFile::getMmap()
method returning SFS_OK and setting the Addr and Size
variables.

This commit replaces the memory mapped file approach of
XrdCtaFile::getMmap() with the stream interface approach of
XrdCtaFile::read().

Please note that the CTA front-end is still not actually
streaming the result of "cta af ls --vid XXXX".  This
commit is one step closer.  The whole reply message is
still generated in one shot by the constructor of
XrdCtaFile.  The contents are however now streamed off
to the "cta" command-line tool via multiple calls to
XrdCtaFile::read().

Removed the "--encryptionkey" option from "cta tape add"

I have updated the help page of the "cta tape" command.  The page
now explains that encryption_key is either "none" or the name of the
individual key to be used.

Please note that encryption and its configuration is not for release
0 of CTA.  It is also not clear how much encryption configuration
details should be inside of the CTA catalogue.  We may for example
drop the concept of encryption_key name all together and just record
a boolean that simply indicates whether or not a tape is encrypted.

The scheduling based on disk throughput estimates will not be implemented in the forseeable, if ever.

This reverts commit e419d922.

After much discussion the commit being reverted has and would have
generated more work than problems solved.