Fallback code for unresolved calls

[stonier]

Whenever a client tries to resolve an address, there should be a mechanism handling the case when that service is unresolved, thereby letting the user know that 'something is up doc'.

[stonier]

Some testing....when I call list_discovered_services I tried to get avahi_service_resolve_new to update resolvable status of each connection, but this is unreliable. After disconnecting a remote client's wireless, sometimes it continues to be 'resolvable', sometimes not. Perhaps this is to do with the avahi-daemon caching data. Is there timeouts involved?

Avahi documentation is not sparse, it's sparse sparse!

http://old.nabble.com/Handling-clients-that-drop-out-or-disconnect-td32750470.html

[stonier]

Another test...

Walk away out of range, dudemaster becomes unresolvable, zeroconf_avahi deletes it from its discovered list, but...when I turn on the wireless again, it doesn't get rediscovered because its already there, just unresolvable.

[stonier]

Solution is to keep resolvers open. There seem to be a couple of bugs in the avahi resolvers, but with a couple of workarounds it can reliably detect up and down of connections and smashing on top of old connections by new ones with the same name - see the wiki pages.

Done.