Run lookups after dial failure NET-384

[kalabukdima]

The current approach

After #199 the clients, e.g. pings collector, are trying to always keep connections to all workers open. This is a separate loop from actually sending the requests to them.
If a request is attempted and there is neither an existing connection nor known addresses of the peer, it just fails immediately. It doesn't trigger new Kademlia lookups because it assumes that the background loop already made the best effort to have that connection open.

The background loop works like this:

• We schedule DHT lookups for all the known workers, putting them in the queue.
• Every lookup for a peer finds many other peer+address pairs along the way. Those addresses get saved to the AddressCache.
• On the next lookup request from the queue, we check the address cache first and only start a Kademlia query if the peer is not yet cached.

As a result

• Some workers are kept connected. On connection close the find_and_dial is rescheduled and the connection gets re-established.
• Some workers don't have addresses in DHT and fall out of the loop. (They are usually dead forever and don't return to the network. But if they do, they won't be picked up until the pings collector restarts, which is a separate issue.)

The issue

Every time the worker changes the address, it drops out of the healthy loop. At least until a happy coincidence returns it to the healthy loop, which usually takes >1h.

Why:

1. The connection to the worker closes, and a lookup is scheduled.
2. The address cache still holds the peer's addresses. A connection closing doesn't evict anything — only a dial failure does. So the cached address is dialed, but no Kad query is issued.
3. That dial uses the stale cached addresses and fails. Now AddressCache::on_dial_failure evicts the entry. But nothing re-schedules the address lookup.
4. Effectively that worker stays disconnected and all requests to it fail with "no addresses for peer".

The fix

The lookups are now scheduled on dial failures caused by unreachable addresses.

On the healthy loop, a stale address triggers a Kad query to get the worker reconnected if there is a reachable address in DHT.
Even if that peer is not reachable yet, it will keep retrying lookups every 30s because Kademlia keeps the last known address and won't evict it. Only if the peer completely drops out of Kademlia (NoAddresses path), it gets dropped from the reconnect loop.