bug #92460: tapebridged should gracefully shutdown a migration tape-session when tapegatewayd reports a disabled tape

Fixed bad behaviour of tapebridged when it has to cope with a DISABLED tape
just before its request for the first file to migrate.

bug #92460: tapebridged should gracefully shutdown a migration tape-session when tapegatewayd reports a disabled tape

Tests for the 2.1.13-0 release have shown that the tapebridged daemon does not
cope correctly with a tape being DISABLED just before it asks for the first
file to be migrated.  The tapebridged daemon incorreectly ends the tape session
with an EndNotification message when it should end the tape session with a
EndNotificationErrorReport.

This commit adds the unit-test that fails if it detects this bad behaviour.

Added support for wiping and re-creating the name server in a dev environement. Followed up with the development of the 2.1.13 version.

Ported missing synonym creation from upgrade script to creation script for name server. Added the creation of the root entry in the same place.

Ported missing creation of the default recallGroup in the stager DB (in tape gateway section).

Fixed a race condition between renewal of configuration and the check whether we should renew that looked at the config (for the timeout) outside of a read lock

Removed unreferenced file.

Fixed stupid mistake by which all tapes were requested to VDQM in read mode. The scarry thing here is that it did not prevent migration to happen !

Added indexes and comment to prevent table locks created by foreign key constraints and explain the situation

used in conjunction with distributed transactions.
Updated upgrade scripts.

endTapeSession be called in that context, and that the tapebridged
should handle the case of receiving a 'no such session/mount' error
if it asks for more work on a session that had to be prematurely failed.

- Fixed cast in byte to hex conversion

- Dropped usage of ScopedTransaction where not needed
- Fixed calls to commit and rollback in OraTapeGatewaySvc
- Several fixes in the migration code (still work in progress)

Some cleanup is needed in the gateway DLF messages, plus the castor/tape/python directory is not compiled any longer, to be eventually dropped later.

Introduced a generic procedure to run DB jobs and log any exception they would throw with its full stack trace.