Improved unit tests.

Fixed a bug in the method castor::tape::tapebridge::TapeFlushConfigParams::determineTapeFlushConfigParams where the configuration parameters were not actually being dteremined.

After further reverse engineering rtcpd it became apparent that there should
only be one configuration parameter to specify which of the following 3 possible
tape-flush behaviours the tapebridged and rtcpd daemons should follow:

  * N_FLUSHES_PER_FILE
  * ONE_FLUSH_PER_FILE
  * ONE_FLUSH_PER_N_FILES

This commit adds the following tapebridge configuration parameter, which today
is ignored:

  TAPEBRIDGE TAPEFLUSHMODE N_FLUSHES_PER_FILE

More importantly and the real reason for this commit is the value of this
configuration parameter is now passed from the tapebridged daemon to the rtcpd
daemon via the tapeFlushMode member of the newly updated TAPEBRIDGE_CLIENTINFO2
message:

typedef struct {
  uint32_t volReqId;
  uint32_t bridgeCallbackPort;
  uint32_t bridgeClientCallbackPort;
  uint32_t clientUID;
  uint32_t clientGID;
  uint32_t tapeFlushMode;
  uint64_t maxBytesBeforeFlush;
  uint64_t maxFilesBeforeFlush;
  char     bridgeHost[CA_MAXHOSTNAMELEN+1];
  char     bridgeClientHost[CA_MAXHOSTNAMELEN+1];
  char     dgn[CA_MAXDGNLEN+1];
  char     drive[CA_MAXUNMLEN+1];
  char     clientName[CA_MAXUSRNAMELEN+1];
} tapeBridgeClientInfo2MsgBody_t;

Please note that the TAPEBRIDGE_CLIENTINFO2 has not been released in any version
of CASTOR and is therefore subject to change until the next release where it
will be frozen.

Before this fix, machines where a job could not be submitted (e.g. because of a timeout) were not removed from the server side scheduling queue. The number of unique pending jobs, derived from this queue was thus wrong.
On top, jobs that would finally fail to start (e.g. because all machines that accepted it are too full) would not answer their submitter, as the server was believing that other machines were still trying to schedule them.

This commit modifies the tapebridged/rtcpd protocol that is internal to a
tape-server.  The new version of the protocol is now capable of supporting
buffered tape-marks, though the version of rtcpd in this commit still only
supports at best one synchronised tape-mark per file, i.e. it does not support
buffered-tape marks over more than one file.

The change with respect to the previous version of to the tapebridged/rtcpd
protocol is simple.  When the rtcpd daemon knows that its client is is the
tapebridged daemon it now sends an explicit TAPEBRIDGE_FLUSHEDTOTAPE message to
the tapebridged daemon when it can guarantee one or more files have been
flushed to tape.  The tapebridge daemon will now only send
FileMigratedNotification messages to the tapegatewayd daemon for the files that
have been explicitly flushed to tape.  The PendingMigrationsStore is used to
hold back FileMigratedNotification messages until the appropriate
TAPEBRIDGE_FLUSHEDTOTAPE message has been received.  The rtcpd daemon in this
commit always does at least one synchronised tape-mark per file and sends
always sends one TAPEBRIDGE_FLUSHEDTOTAPE per file when its client is the
tapegatewayd daemon.

I broke the build with my last commit because I have a different version of the BridgeProtocolEnigine class.  Problem now fixed.

Added the class implementing the pending migrations store that will eventually be used to implement buffered tape-marks.

Schema version bumped up for VDQM, and upgrade created for next official release
(it has already been run on the dev VDQM instance).

Bug #83111 (CM: Remove Id2Type and the logic around it from the CASTOR schemata). Set object type before all remaining calls to createObj() that were left behind.

Refactored tapebridged in order to facilitate implementimg this RFE.

Fixed missing call to setObjType that prevented recalls to happen. This was forgotten when Id2Type was removed

Fixed bug #84599: deadlock in testsuite when output of stager_qry is too long. This was due to the subprocess module itself where poll and stdout should never be used

The tapebridged daemon now determines and sends the values of the following
three CASTOR configuration parameters to the rtcpd daemon:

TAPEBRIDGE USEBUFFEREDTAPEMARKSOVERMULTIPLEFILES false
TAPEBRIDGE MAXBYTESBEFOREFLUSH 8589934592
TAPEBRIDGE MAXFILESBEFOREFLUSH 100

Please note that the support for buffered tape-marks over multiple files has
NOT been implemented.  On top of this, lines 91 to 109 inclusive of the file
named rtcopy/rtcpd_GetClientInfo.c prevent buffered tape-marks over multiple
files from even trying to start and these lines create an error message that
explicitly tells the user that buffered tape-marks over multiple files is not
supported.

 91   /* This version of rtcpd does NOT support buffered tape-marks over */
 92   /* multiple files                                                  */
 93   if(*clientIsTapeBridge &&
 94     tapeBridgeClientInfo2MsgBody->useBufferedTapeMarksOverMultipleFiles) {
 95     char dummyErrbuf[32]; /* For fire and forget */
 96     char *const ackMsg =
 97       "Buffered tape-marks over multiple files is not supported";
 98   
 99     /* Fire and forget negative acknowledgement to VDQM or tape-bridge */
100     rtcpd_SendAckToVdqmOrTapeBridge(connSock, netTimeout, msgHdr.reqtype, -1    , 
101       ackMsg, dummyErrbuf, sizeof(dummyErrbuf));
102 
103     snprintf(errBuf, errBufLen, "%s()"
104       ": %s",
105       __FUNCTION__, ackMsg);
106     errBuf[errBufLen - 1] = '\0';
107     serrno = ENOTSUP;
108     return(-1);
109   }

documentation.  No real meat to this update, just keeping the documentation
up-to-date.

Updated tpcp commands on the trunk to display the information about the file
that caused an end of session because it generated a file specific error.

(Seen during debugging of case sr #122264: GC very low file age in FIFO pool).

Merged the branch named v2_1_11Version_bridge_error_handling into the trunk.

The problem was with getting a new conversion service when the connection was dropped. We are now using our own one directly, without help of the rmMasterSvc, so that there is no problem anymore.

Merged new DLF constants from v2_1_11Version_bridge_error_handling branch into
the trunk.

The connection to the DB is now shared between all TrasnferManagerService instances, as one is created per connection.
Note that the monitoring of this case has also been improved.

Added to the tapebridged daemon the getting of the following tapebridged
configuration parameters:

TAPEBRIDGED MAXBYTESBEFOREFLUSH
TAPEBRIDGED MAXFILESBEFOREFLUSH

Please note that these parameters are not yet passed on to the rtcpd daemon.

Fixed compilation errors.

Fixed compilation errors.

Added support for a new request in the tape gateway: we will fail in sequence a file transfer and a tape session when the bridge report such a problem.

Failure to fail a file will still allow the failure of the tape session.

Forward ported the umbrello modifications from 2.1.11. Rest to follow later when developement is done.

The cprc (file copy return code) of the rtcpd message called RtcpFileRqstMsg will needs to be interpreted by the tapebridged in order to implement a fix for this bug.  It's datatype is currently wrong, it is defined as being uint32_t when it should be signed.  The following commit fixes this problem on the trunk.

Added new tapebridged configuration parameter:

TAPEBRIDGED USEBUFFEREDTAPEMARKSOVERMULTIPLEFILES