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