eliminate a deadlock
Golang locks aren't re-entrant. As result one can get deadlocks on
RWMutexes like this:

goroutine #1: attempt to acquire read lock -> success
goroutine #2: attempt to acquire write lock -> wait
goroutine #1: attempt to acquire read lock again -> wait

(a pending write lock prevents subsequent acquisitions of read locks)

Peer.HasPathTo could run into this since it could attempt to acquire
the read lock on a peer multiple times if previously it had
encountered that peer via an asymmetric connection.
oops
Don't splode in error type checks if given nil

These two testing utils assumed that they got an error, and checked
its type; however, the most likely failure case is that there's no
error (i.e., nil). In that case they would cause a NPE panic.
Merge pull request #256 from squaremo/dont_splode

Don't splode in error type checks if given nil
Cope with duplicate name->IP entries

The zone DB no longer considers duplciates of (IP, name); it will
reject duplicates of (IP, name, ident), but this ultimately doesn't
matter since those are all the fields it records anyway.

The HTTP interface treats these duplicates as trivial success (i.e.,
it acts as if it's idempotent, which it is).

This changes the behaviour for removals: if (IP, name) is recorded for
two different containers, removing one will leave the other extant.