srm: Fix request expiration

Fixes an issue in which request expiration caused requests to be marked
as completed with success rather than as failed. The same issue would
also lead to messages about illegal state transitions from Failed to
Done in the log file.

The Job base class supports expiring jobs. When a job is already in
READY or TRANSFERRING, it doesn't fail the job - instead it is marked
as done successfully. I can only guess as to the motivation for this:
Probably becaues for get requests, the TURL is still usable and if
the client got the TURL then the transfer is likely going to succeed.

For put, the put container request had an override for the expiration
to fail the request no matter the state (as long as it is not final
already). However the expiration check is applied to both container
requests and file level requests. The consequence was that although
the container request was marked as failed, the file level request
would be marked as done successfully if expired before the contain
request. Consequently the file was not deleted.

For some requests, the SRM is quite clear that the expiration should
result in SRM_REQUEST_TIMED_OUT. For other requests (eg get) the
text says it should be returned, although the return code is not
listed as a possible return code of srmPrepareToGet. For ls, the
possibility of a timeout is not mentioned at all. I decided to
consider these as flaws in the spec and return SRM_REQUEST_TIMED_OUT
for all expired requests.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.9
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6997/
(cherry picked from commit 4837397fb0c48305e610233f8e446e5b19cee44a)
Merge pull request #560 from gbehrmann/fix/2.9/rb6997

Fix/2.9/rb6997