Renamed castor2fs to castor for the URL parameters and added a pfn2 parameter to URLs for disk-to-disk copies

        "castor2fs." to "castor."

        a random ones using uuid.

        also include this new information when computing the signature of each
        transfer. The transfer type for client requests is "user".

Implemented the diskmanager side of the OPEN call from movers, to be used by xroot for user transfers as well as to notify internal (in particular tape) transfers

Dropped listing of tape transfers: this is going to be replaced by querying the xroot server for the ongoing transfers

Reworked the physical layout of the SubRequest table: now it is partitioned by 5 groups of statuses + subpartitioned by hash(id) to spread the load

Tests using writetp were no longer passing due to the new
"terminate session early" logic of the tapeserverd daemon.
The daemon was askng for a minimum batch of 250 files. The
writetp command only ever gave one file per batch of work.

An attempt to introduce proper for protobuf dependencies as the previous solution led to systematic recompilation.

errors for a non-crashing session can also be recorded as a failures in the
tape log.

First verion done.

Fixed error reporting of the RunningTransferSet in case of jobs killed before there were even started (and thus having no process associated)

        the client has arrived at the diskserver and is starting the transfer

    The information provided in response to a XrdCl::Query command is in the form of a
    string which represents the list of transfers and each transfer is a tuple having
    the following structure:
	(tident,castor_path,tx_type,isRW,ReqId)
    - tident contains: userid.procid:fd@client_host
    - castor_path is the physical path to the file as represented in the CASTOR world
    - tx_type can have one of the following values: user, tape, d2duser, d2dbalance,
      d2dinternal, d2ddrain or unknown. This is easily extensible as whatever is
      received in the opaque information with the tag "castor.txtype" is returned at
      this stage
    - 0 for read operations 1 for write operations
    - ReqId - request id in case of user initiated transfers i.e. transfers that go
      through the XRootD headnode and will be 0 for all the rest of the transfers that
      don't have a request id

Conflicts:
	ReleaseNotes
	castor/db/stager_oracle_create.sql
	debian/changelog
	ns/cns_oracle_create.sql

koji/linuxsoft