webdav: Fix problems with root paths

Addresses several issues in the webdav door:

- HTTP PUT without redirect is broken in earlier versions of 2.6. This
  regression was introduced in b460302934a6dab2cde1202a38883552d62ac65d.

  The problem is that the the resource path after upload is produced by
  concatenating the server's root path with a full dCache name space path,
  thus the root path appear twice in the generated path.

- The URI name space depends on who authenticates, which means that the
  same URI can have several meanings. This makes bookmarking and linking
  difficult.

- The CSS refers to a non-existing background image.

The solution to these problems are related. The patch removes the
webdavChrootToUserRoot property. An authenticated users root directory
is now always enforced, but only by checking that the request is within
the users root path. If a user has a non-null root and accesses the
root of the webdav door, a redirect to the users home directory is
generated.

The above change resulted in repeated authentication requests in the
browser, because the browser would try to access a non-existing
background image and a non-existing favicon.ico file. Access to these
would be denied, as they are outside the users root directory, and
thus the browser would ask for another user name and password. To
solve this problem, the patch fixes the CSS and adds a favicon.ico file.

An earlier version of this patch was submitted as http://rb.dcache.org/r/5201/

Target: trunk
Request: 2.6
Require-book: yes
Require-notes: yes
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/5672/
Merge branch 'master' of https://github.com/dCache/dcache
dcache: (remote logging) change default server port to be outside ephemeral port range

module: dcache (alarms)

This patch is an added precaution in connection with http://rb.dcache.org/r/5664.  It was discovered that the default port suggested by ch.qos.logback for the SocketAppender and server, 60001, is in fact not a good choice because it lies within the ephemeral port range for some OS's.  When there is no endpoint listening (I believe this only occurs when the server is supposed to be running local to the client domain), that port can be chosen as source for establishing a connection, such that the appender then ends up connecting to itself.  If events are actually sent over this connection, it quickly fills up the buffer and blocks.  This causes all threads which do logging to block, effectively freezing the system.

The above-mentioned patch sets remote logging by default to off, so that events are not sent unless it is explicitly activated.  The self-connected appender, however, is still potentially present (though at the 10 second reconnect timeout -- which is what the logback.xml is configured for -- it will take a while for it to find the 60001 port).

Setting the default port outside most ephemeral port ranges will guarantee that this connect-back does not happen.

Testing done:

Using a small test class with the remote logger reconnect delay set to 1 ms, and no server endpoint running, port 60001 was first chosen.  After 30 seconds,

[root@otfrid dcache]# netstat -anp | grep 60001
tcp        4      0 127.0.0.1:60001             127.0.0.1:60001             ESTABLISHED 6051/java

was seen.  The test waits 60 seconds, then begins to log continuously. The system freezes after 5446 events:

6001 25 Jun 2013 08:03:24 [] error message 1
...
6001 25 Jun 2013 08:03:24 [] error message 5446

Rerunning with port set to 9876 shows that after 10 minutes and more than 17M events, no connection is established and hence no freeze.

Target: master
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Gerd
Bug: http://rt.dcache.org/Ticket/Display.html?id=7856

RELEASE NOTES:

The default port for remote logging has been changed from 60001 to 9876; the latter lies outside most OS ephemeral port ranges.  This avoids a situation in which the connection host is localhost (the default), but there is no server listening on that port, thus permitting that port to be chosen as source for the appender connection and consequently establishing a connection to itself.  When this happens, the buffer quickly fills and blocks further logging, freezing all threads that do logging (effectively the entire domain).