Yield in setup

Here's the change for having setup() a bit more readable.
Unfortunately I had to split setup() and _setup().

A coroutine is a generator, which means that needs something to yield from it to generate something.

Simply doing:
loop.call_later(setup)

def setup(self):
  yield from foo
  log(something)
  yield from bar

won't work, since when setup() is called back by the loop, will return a generator, which needs something to have it produce the results. The only way for the loop to have it done is to:
- have the generator yielded from by some other coroutine
- use Task (asyncio.async() in this case wraps around it)

In other terms, setup now removes itself as writer and then calls asynchronously _setup() which eventually will add the default writer, after having setup everything.

It should not be a problem, flow-wise, i find just uglier than I though, to have to split it.

*NOTE* Please test it in a real HW env, before merging. I tested it on my env with a simple stub, which does not highlight any real HW problem.

Also, I updated some of the unittests you amended, for completeness:
- check that the callback is also called, after a read
- that in case of empty queue, no blocking write() is called
Sorry, I didn't get your actual question.
My understanding is that doing yield from, you actually reenter the loop, so the setUp is not  blocking. when the yielded coroutine returns, setUp keeps on from there (normal yield behaviour).

setUp risks to be a big chunk of blockng code, so either you break it with call_soon()s chaining correctly the calls (setUp which call_soon(setUp_phase1), setUp_phase1 calls_soon(setup_phase2), etc to ensure that no races occurs), or you use 'yield from', which allows you to have the flow of the code already 'chainined' since it's a generator.