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 to 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).

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 the 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
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/6360/