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/
srm: Fix request cancellation due to SURL deletion

An srmRm cancels requests on the SURL that is deleted. The code however just
changed the state to CANCELED rather that calling abort and thus for put
requests the put wasn't properly aborted - in particular the upload directory
isn't deleted, resulting in those leaking.

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/6998/
Revert "srm: Drop fail fast for protocol checks"

This reverts commit 0f5a4d579476094c12e393bd14fdccb90ba99826.
chimera: Fix duplicate key supression

The postgresql driver for chimera has logic to avoid duplicate key
errors in postgresql while still throwing the SQLException on the
client side.

Unfortunately, the error code used is inconsistent with the error
code used in other logic that supresses the duplicate key error.

This patch resolves the problem: I checked the other places the
modified methods are called, and code that doesn't rely on the
isDuplicateKeyError just checks whther the error code starts with
'23'. This will still work after the change.

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6999/
xrootd: split protocol name form the client IP in XrootdProtocolInfo

Acked-by: Paul Millar
Target: master, 2.8, 2.9
Require-book: no
Require-notes: yes