srm: Make FTP TURLs absolute

RFC 1738 defines that FTP URLs are interpreted relative to
the initial working directory of the FTP session, which may
be different from the root. In dCache the user's home directory
is the initial working directory. The TURL generated by the
SRM thus doesn't refer to the correct directory if dCache has
been configured with home directories.

The spec states that an absolute path should be encoded with
starting as %2F. That's because the spec requires the client
to split the path at / and use each segment in a CWD command
(plain FTP doesn't have a concept of paths; path names are
an extension defined in RFC 3659). Ie gsiftp://localhost//foo/bar
just means to do

CWD
CWD foo

and then STOR or RETR bar. gsiftp://localhost/%2Ffoo/bar means

CD /foo

and then STOR or RETR bar.

However our own srmcp client doesn't deal with the URI encoding
and just sends %2F as part of the directory name.

Globus Toolkit (globus-url-copy) doesn't follow the spec either,
since it prefixes the path in gsiftp://localhost/foo/bar with an
extra slash, thus with Globus it isn't possible to refer to
something relative to the user's home directory.

Both srmcp and globus-url-copy do not interpret the empty
path element according to the spec since they just pass the
entire path on to the server. Ie. for gsiftp://localhost//foo/bar,
srmcp sends /foo to the server, while globus-url-copy sends
//foo. At the FTP level the double slash is undefined, but our
FTP door collapses it into a single slash.

The conclusion from the above is that we cannot use the spec
compliant encoding as it would break compatibility with our
own client. We can prefix the path with an extra slash, which
works with both Globus and srmcp. It will not work with a
spec compliant client, however the current code doesn't work
with a spec complaint client anyway, so the situation doesn't
become worse.

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