log: add filters

* filter log entries with new method setLogFilter
* filter by node id, search or infohash
* add optional parameter to 'log' in dhtnode

* several clang related bug fixes;
* connectivity changes related enhancements;
* new "refresh" protocol primitive (not exposed to API);
* "permanent put" operation fixes/enhancements;
* fixed general efficiency issues;

Simon Désaulniers authored 8 years ago and Adrien Béraud committed 8 years ago

Historically, the next announce timing was based on the last acknowledgement
received from a SearchNode. This behavior was invalid since the 'refresh'
operation. In fact, for a given value that was "refreshed", its creation time
would differ from the announcer's info. Therefor, all search node's
reannouncing timings would differ, hence causing inconsistency on the network.

dht: appropriate time info in permanent put ops

Simon Désaulniers authored 8 years ago and Adrien Béraud committed 8 years ago

This operation requests a node to refresh a value's time_point information of
its lifetime begining. This is intended to fix the *permanent put* operation
which has been having syncing issues since the introduction of an enhanced and
lighter put operation.

* automatic connection loss recovery
* dhtrunner: asynchronous DNS lookup for bootstrap
* handle values up to 64k
* better support for large values on macOS
* dht: add callback to pingNode
* fix compilation with recent clang versions

search: detect connectivity changes

The number of bad nodes is limited in order to help determine presence of
connectivity changes. See https://github.com/savoirfairelinux/opendht/issues/137
for details.

According to the tables, 25 is a good average value for big networks. If the
network is small, normal search expiration process will handle the situation.