pnfsmanager: Add support for temporary upload paths

This patch adds operations to pnfs manager for creating, commiting and
cancelling temporary upload paths. Such paths can be used to write a new file
to dCache without exposing the existence of the file untilt the upload
completed. A temporary upload path is revocable. These features make it ideal
for generating unique write TURLs for use with SRM, although other use cases
exist (eg. xrootd POSC semantics could be achieved using a temporary upload
path).

How to construct a temporary upload path is a detail of the name space provider
implementation. ChimeraNameSpaceProvider uses a dedicated upload directory (the
default value being /upload) with mode 0711 to create a temporary directory
with a cryptographically strong UUID. Tags of the real upload directory are
copied to the temporary directory, thus ensuring that the file gets the right
storage class, access latency, retention policy, etc. While creating the upload
path, an optional expected file size, access latency, retention policy and
space token can be injected. These too are stored as tags in the temporary
upload directory.

Chimera is extended to allow a directory with a set of tags to be created
without copying the parent tags. Unfortunately the Chimera postgresql driver
copies the tags in a trigger, which makes that optimization ineffective. One
could argue that this functionality doesn't belong in a trigger and instead
should have been implemnted with a stored procedure for creating directories
with inherited tags - the driver could then have called the stored procedure
explicitly rather than relying on the trigger. This is left as a future
optimization.

The actual upload to the temporary path is a regular upload, with the exception
that the expected file size and real path are injeced into the CreateFile reply
from pnfs manager.

The upload directory is automatically created the first time this feature is
used. A site not using a protocl relying on unique upload paths will never see
the upload directory.

Since doors may export a different directory as their name space root, the
unqiue write paths are only useable if the upload directory is visible through
the doors. A non-default root path is a primary reason for changing the default
upload path. A typical value may be /pnfs/example.org/data/upload, with
example.org being the site domain name. This can be adjusted by setting
dcache.upload-directory.

Since doors only allow access to a user's root directory, doors have been
extended with an authorization exception allowing access to the upload
directory. Thus a non-default upload directory has to be configured on both
pnfs manager and all doors.

Ownership of the temporary upload directory mimics that of the file that is to
be created. The temporary upload path is thus writable to the same user that
requested the path to be created. One may imagine refining this in the future
to allow anonymous protocols to be used for writing to the upload path (eg to
create single use write URIs that one can use with protocols without
authorization, or that one can give to somebody else to upload a file to [a
form of delegation]).

The changes were originally part of the unique write TURL patch, but have been
split out for easier reviewing. The code in the patch is mostly unused at this
stage.

Target: trunk
Require-notes: yes
Require-book: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6690/