Fix for issue 13 (panic when connTable is stopped)

[StefanKopieczek]

Hey,

This PR makes the following changes:

• Add a wrapper timing for the built-in time library, so that we can mock out time-dependant code for testing.
• Move the transport library over to using timing rather than time for real-time calls.
• Add a few initial transport tests (enough to reproduce the problem)
• Completely rewrite connTable to fix a bunch of race conditions, and also incidentally issue #13 . The general approach is to move responsibilities from the connWatcher into the connTable – most of the race conditions I spotted were due to unclear ownership.

It's not a huge review, but needs a bit of thought regarding the threading model, so don't feel you have to turn it around ASAP :)

Cheers :)

[rynorris]

Generally great work! :)

I'm a little sceptical that the channel-based model for synchronizing access to the conntable is the best. Thinking it might make more sense just to use a good old-fashioned mutex to avoid the overhead of extra allocations for response channels and message passing. Happy to leave it for now though and revisit if it becomes a perf bottleneck.

[StefanKopieczek]

Agree; I felt the channel idiom was a little stretched here; I felt that mutices would be an admission of defeat, but you're probably right. Let's revisit later though - I can't quite face rewriting it again right now!

[StefanKopieczek]

OK, pushed 4ef9e1f35009cbc83e8ea307d0c0df2d7bc8bc1a with markups. Please re-review and merge if happy.