srm,pool: improve support for 3rd-party HTTP copy

This patch improves SRM's existing support for HTTP 3rd-party copy.
With this patch, both push and pull requests are supported and both
unencrypted (http) and encrypted (https) targets will work.  For
encrypted connections where the pool is pushing a file to a third
party, an optional client credential may be supplied.

Both transfer directions will attempt to check data integrity: if the
remote server provides Content-Length as part of a GET or HEAD request
then this is used to verify the length of data; if the remote server
supports RFC 3230 and the server provides a "useful" checksum then
this is used to verify data was not corrupted in transit, where
"useful" means any checksum generated with an algorithm dCache knows
how to generate (for pull requests) or any checksum that dCache
already knows for the file (for push requests).

The mover considers the data integrity to be verified if all of the
following hold:

    remote server and dCache agree on the content length

    remote server and dCache agree on at least one checksum
    algorithm's value

    no remote server supplied checksum disagrees with any checksum
    dCache knows for the file.

If the mover detects that any of these conditions failed then the
mover will fail the request.  When pushing data (HTTP PUT) and the
mover fails the transfer then it will attempt to delete the remote
file by issuing a DELETE request.  While not ideal, this seems the
least-worse method of dealing with such failed transfers.  The DELETE
request may fail; if so, the error message sent to the client is
adjusted to indicate the remote server may contain incomplete or
corrupt data.

The mover accepts an option 'requires-verification', which controls
the behaviour when the remote server provides insufficient information
to verify data integrity.  If requires-verification is false then
dCache will accept or send data when data integrity cannot be
verified; if true then the mover will fail the request.

The mover also accepts zero or more (arbitrary) HTTP headers when
requesting a file be transferred.  This allows the requester to
customise the HTTP request that the pool sends to the remote server.
Such headers could include authorisation information or some other
information to steer how the remote server handles the HTTP request.

The SRM Copy request includes a list of arbitrary key-value pairs
called ExtraInfo.  This allows the client to specify additional
information that is platform-specific.  When processing such
remote-copy requests, the generic SRM-server layer now passes this
ExtraInfo to the AbstractStorageElement plugin.  The SRM
CopyFileRequest database storage has been updated to store this
information so it is available when restarting the SRM.  The same
approach may be used in the future for other requests, if necessary.

The dCache AbstractStorageElement plugin has been updated to use
ExtraInfo information to control the behaviour described above.

If ExtraInfo has an entry with 'verify' key is sent then the value is
parsed as a boolean value.  If 'true' then dCache will fail requests
where the data integrity cannot be verified, other values will result
in dCache accepting such transfers.  If the 'verify' key is not
specific then a configurable default is used.

If ExtraInfo contains entries with keys that start 'header-' then the
'header-' part is stripped from the key and the resulting key-value
pair is used as an HTTP header when making requests to the remote
server.

The srm-client has been updated to allow the user to specify arbitrary
ExtraInfo information.

Target: master