pool: Clean up local interface resolution in HTTP transfer service

I don't see a reason for the complicated fallback in the loop - it
appears that it would never be used. A similar change was recently
made in the xrootd transfer service.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5452/
nfs4: Add .(get)(filepath)(locality) command to NFS4 (revised)

module: nfs4, chimera, core, dcache-chimera

Adds dot command to nfs4 interface in order to get live file locality information about a given file.

A special subclass of the JdbcFs calls out to PoolMonitor for dynamic information rather than accessing the Chimera database directly. This is done using a Guava cache loader with a lifetime of 1 minute.  The only way I could get this to work was to cache the actual FsInode.  FsInode_PGET now returns a list of name=value pairs, line-separated.  This need not be set in stone, though.

NOTE:  I just noticed that the parent Jdbc class is defined as @immutable and @threadsafe.  While I believe that thread-safety is still the case, the immutability of the subclass does not apply, given that we now have live state in it because of the caching.

I am unsure whether this will cause problems.  However, the only path affected here is on ".(get)..." calls.

Patch: http://rb.dcache.org/r/5409/
Acked-by: Tigran
Target: trunk
Require-notes: yes
Require-book: yes

RELEASE NOTES:
BOOK:

On a mounted chimera (nfs4) partition, it is now possible to do:

cat ".(get)(<filename>)(locality)"

in order to find out file locality (status), i.e., ONLINE, NEARLINE, UNAVAILABLE, etc.  This status should reflect actual network availability rather than the static state stored in the database.

Deployed and tested with existing and non-existing file paths, observing the proper no such file error message for the latter.