Upgrade dependencies

Target: trunk
Require-notes: no
Require-book: no
spacemanager: Postpone DB update to intercepted pool accept message

A recent patch moved the DB update on transfer to the intercepted
pool selection reply. This patch moves those updates even further
back so that they now happen in the intercepted pool accept request,
which triggers the creation of a mover in the pool.

There are several benefits of this change:

- If pool selection took a long time and the door no longer exists
  (client gave up), then we now do not create any temporary reservations.
  Before a temporary reservation would be created, but since there
  would not have been a DoorTransferFinishedMessage or any other
  message to indicate a failure, the temporary reservation would not
  be cleaned until it expired.

- In case a component does a pool selection without starting a mover
  (eg older versions of pin manager or SRM would do this), doing the
  reservation update in the pool selection is clearly wrong.

- More messages of transfers without space reservation can now
  bypass queuing in space manager. This is because the LinkGroup entry
  in storage info is now passed to the pool and can be used as a
  simple test whehter additional processing in space manager is
  required.

- We are one step closer to being able do pool selection in doors: since
  space manager no longer updates its database on pool selection, we could
  load all information needed to select a linkgroup into memory, serialize
  it and transfer it to doors (just like we do with pool manager's
  PoolMonitor).

To implement this, I had to add a field for preallocation to the
pool accept message - I imagine the pool could make use of this
information too to preallocate space during mover startup or reject
a mover if not enough garbage collectible space is available up
front.

Temporary reservations created by space manager (when reservation
for non-srm transfers is enabled or a default space token is defined for
the target directory) are no longer bound to the path - the reservations
are created directly with a pnfs id and the path field is null (this
change is admin visible).  This has two benefits:

- There is no risk of duplicate paths. A failed upload will not block
  a subsequent retry even if the retry is performed before the delete
  notification reaches space manager.

- In case of failures, space manager can recognize which reservation it
  created itself (those without a path) and delete those rather than
  unpin the pnfs id (a reservation without a path would not be useable
  to any future transfer anyway as there is no way to bind that transfer
  to the reservation; the only point of having the path in space manager
  is so SRM can create entries before a PNFS ID has been generated).

One consequence of th patch is that space manager once again intercepts
the pool accept message. In return the pool selection reply is no
longer intercepted, thus this change should not affect latency.

Target: trunk
Require-notes: yes
Require-book: no
spacemanager: Do not delete SRM managed reservation entries on file deletion

SRM creates file entries in space reservations prior to asking a client to
upload a file through some transfer protocol. It is valid for a client to retry
a failed upload without renegotiating the transfer with the SRM (our own srm
client does this). However when the name space entry is deleted after a failed
upload, the space manager marks the file entries as deleted and possibly
deletes the file entry from its tables (depends on whether a disk replica was
registered at that time). Thus when the client retries the upload, the upload
will fail or a temporary reservation will be created and used instead of the
one managed by the SRM.

This patch addresses this problem by not deleting entries/marking entries as
deleted in state RESERVED or TRANSFERRING unless they do not have a path
associated with them (entries without a path cannot be reused anyway). Instead
such entries are reset to RESERVED and the associated PNFS ID is removed.

The patch also cleans up some related code.

Target: trunk
Require-notes: yes
Require-book: no
Ticket: http://rt.dcache.org/Ticket/Display.html?id=7799
spacemanager: Mover DB schema management to Liquibase

Target: trunk
Require-notes: yes
Require-book: yes
spacemanager: Maintain aggregated fields with database triggers

Moves the logic to maintain aggregated fields in srmlinkgroup and
srmspace from Java code to database triggers.

This is a proof of concept implementation that only adds triggers
for HSQLDB. The patch will be updated with PostgreSQL triggers.

Target: none
Require-notes: yes
Require-book: no