Fix issue #142

[cjerdonek]

[Fix for issue #142] This issue was quite tricky for me to develop a test case for. The hardest part is that you need to find a way to call cancel on close() when it is at this particular line of code. I was led to do that in a roundabout way.

I'm open to suggestions on ways to simplify the test or on ways to eliminate the need for sleeps (which could potentially lead to test flakiness, though the sleeps are quite large currently). Or if it's good enough for the time being, that's fine too!

[cjerdonek]

FYI, I updated the test case in the PR to have only one call to asyncio.sleep() that isn't "minimal." (In contrast, the asyncio.sleep(1) call is minimal in the sense that it doesn't actually wait for 1 second but instead waits the minimum amount of time.) The non-minimal call is needed to give close() enough time to advance far enough into its execution so that it is actually waiting on the worker.

[cjerdonek]

Ping, @aaugustin. Just wanted to make sure you had seen this. No rush, just hadn't seen an acknowledgment of the diagnosis, etc.

[cjerdonek]

Rebased, fixed flake8, and added changelog entry.

[cjerdonek]

Rebased.

[aaugustin]

Since the bug and the fix are in protocol.py, the test should be in test_protocol.py. Writing a test at a lower level is "easier" (not "easy") because you can control exactly which inputs are fed into the event loop and what happens it what order. See 0ae899c.