Support unannounce, move to maxAge instead of timeslotting

[mafintosh]

Implements support for distributed unannounce using webtorrent/bittorrent-dht#184 which means that services when shutting down gracefully can tell the DHT to unannounce itself (NOTE: if we want to land this, we shouldn't merge it until the DHT pr has landed most likely).

Also moves the timeslotting behaivor to use maxAge instead, since this is the intended use of that.
If you want I can split up the PR in two parts, one for timeslotting and one for unannounce, but the two go nicely hand in hand.

If we land unannounce, I suggest we increase the default timeslot to something more like 2-5 min, since services most of the time will be able to unannounce themself, so there will be less dead nodes in the dht. This should drastically reduce the announce traffic on the dht

The link client PR that allows a link to unannounce is here, bitfinexcom/grenache-nodejs-link#10

Let me know what you think :)

[mafintosh]

Forgot to mention, I was gonna add tests, if we wanna land this of course

[prdn]

I like the idea a lot.
At first I was thinking: if we increase the timeslot then we are in the situation where if something fails is harder to find it out.
But in a real world scenario we have redundant workers for each service. So we'll see the clients periodically (randomly) trying to hit dead services for 2/5 mins but we should be likely in the situation where most of the other workers (for the same service) are alive, so the error rate should be contained.
Thanks @mafintosh

[mafintosh]

@prdn yea, and with unannounce we can unannounce a bad service manually, assuming you are on the box with the same hostname, so we might want to add an cli that could that that.

most of the time services would unannounce gracefully as well, so the 2-5 min failure scenario is only a problem when something has a catastrophic failure. will still happen but less likely

[prdn]

@mafintosh @robertkowalski wondering if we can remove the timeslot all together.
If we make https://github.com/webtorrent/bittorrent-dht/blob/master/client.js#L781 configurable also with a time span, then we can avoid the timeslot on grenache-grape
Right now the timeslot is a parameter that needs to be shared exactly by all the grapes, while without it network configuration would be easier.

[robertkowalski]

@prdn good point! talked to @mafintosh, basically that was the intention, but the maxAge option in bittorrent dht was not used. added it in webtorrent/bittorrent-dht#186

[prdn]

@robertkowalski can you open a separate PR for Grape, to allow the configuration of the maxAge parameter for PeerStore (also in the command line version)?

[robertkowalski]

sure! had to add tests, will do when the patch landed in dht master

[prdn]

@mafintosh can we call this dht_timeslot or dht_peer_maxAge ?
edit: I'm referring to this.conf.timeslot that should be renamed into dht_peer_maxAge

[prdn]

@mafintosh would be cool to support it as parameter here https://github.com/bitfinexcom/grenache-grape/blob/master/bin/grape.js