Fix race condition in test and other test bugs

[kentquirk]

Which problem is this PR solving?

This fixes #161 and a couple of other issues discovered while debugging it.

The immediate problem is that running the test under -race worked on my machine, while running without it hung forever.

Short description of the changes

• There was a race condition in the assumptions made by the test code -- the test code needed Add() to run before Flush() but on a fast machine, it might not finish in time. (It was confusing to debug because the test code is trying to induce potential race conditions!)
• There was an assertion in a test comment that a write to a nil channel would panic, but in fact, a write to a nil channel blocks forever. I changed the test to use a closed channel instead, which will panic if it occurs.
• Two successive statements attempted to log the same value (the length of a queue), but under concurrency they might not be the same value, so I added a temp var.

[vreynolds]

I think we can use metrics to wait for the Add deterministically (wait for messages_queued to be the right number), but it's probably not worth the hassle of setting up metrics, eh?

[kentquirk]

I actually tried that with a testMetrics implementation, but it failed because the metrics are updated before the item is added to the queue. So you can still see deadlocks sometimes. This way isn't pretty but I haven't had it fail yet.

[robbkidd]

Rubbin' some sleep on it.