implement (optional) 60-second "connection is old" heuristic

[Brian Warner]

The fixes in #28 help deal with duplicate connections when both ends of the wire are speaking a new version of Foolscap (>0.1.7). To respond well with clients with <=0.1.7 code, there's a heuristic we can use: if the existing connection is more than 60 seconds old, accept the new offer. If it's less than 60 second old, reject the offer and stick with the existing connection.

I'm not a big fan of arbitrary timers, so this trick will be off by default, and there will be a Tub option to enable it.

[Brian Warner]

Done, in [399c2aa9d53a9293dfc83c76f4f3d8403660bc56]. Still needs docs, but I'll probably do that after this next release. For reference, the magic incantation is:

 tub.setOption("handle-old-duplicate-connections", True)

[Brian Warner]

Oh, one final thought: it might be a better idea to base this "broker is old" test against broker.dataLastReceivedAt, rather than broker.creation_timestamp . The idea would be to not allow an offer (perhaps from an evil-twin peer that was configured with the same tubid) to displace a connection that is still in use, where "in use" means "has received data in the last 60 seconds".

The reason I didn't implement it this was is that dataLastReceivedAt is optional (albeit enabled by default). Also, I'm not entirely sure that this alternate behavior is any better.