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.