dcap: better handling of client-supplied unresolvable hostname

The dcap protocol has the client send its hostname to the server when
opening a file in 'active' mode.

Under some circumstances, our current client becomes confused and
sends a name that the server cannot resolve. (This happened to me when
using a laptop without Internet connectivity, but I'm unsure how
exactly to reproduce this.)  The current code assumes the
client-supplied hostname can be resolved.  As a result, when the name
cannot be resolved, an NPE is generated, which is logged in the
server:

06 Jul 2013 15:33:15 (DCap-gsi-vedrfolnir-/C=DE/O=GermanGrid/OU=DESY/CN=Alexander Paul Millar-101) [] Uncaught exception in thread Thread-130
java.lang.NullPointerException: null
        at diskCacheV111.doors.DCapDoorInterpreterV3$IoHandler.getIoDoorEntry(DCapDoorInterpreterV3.java:1966) ~[dcache-dcap-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at diskCacheV111.doors.DCapDoorInterpreterV3.ac_get_door_info(DCapDoorInterpreterV3.java:803) ~[dcache-dcap-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source) ~[na:na]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_21]
        at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_21]
        at dmg.util.command.AcCommandExecutor.execute(AcCommandExecutor.java:157) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.util.CommandInterpreter$CommandEntry.execute(CommandInterpreter.java:385) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.util.CommandInterpreter.execute(CommandInterpreter.java:281) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.util.CommandInterpreter.command(CommandInterpreter.java:215) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.cells.nucleus.CellAdapter.executeLocalCommand(CellAdapter.java:1020) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.cells.nucleus.CellAdapter.messageArrived(CellAdapter.java:939) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$DeliverMessageTask.innerRun(CellNucleus.java:1020) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:929) ~[cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_21]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_21]
        at dmg.cells.nucleus.CellNucleus$1.run(CellNucleus.java:657) [cells-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
        at java.lang.Thread.run(Thread.java:722) [na:1.7.0_21]

When this happens, the client waits and retries.  The retry will use
the same hostname, so will generate a fresh NPE stack-track.  The
client (at least, dccp) appears not to time out; therefore the
transfer will appear stuck until the user (or batch system)
intervenes.

The server should be robust against such client-side mistakes.  Dcap
clients allow the user to override which hostname is sent, which both
introduces the possibility of human error and allows the situation to
be simulated.

This patch allows the server to better handle this failure mode.  A
CacheException is thrown, which is propagated to the client and
terminates the transfer immediately.  The problem is logged at debug
level.

Target: master
Requires-book: no
Requires-notes: no
Patch: http://rb.dcache.org/r/5717/
Acked-by: Gerd Behrmann