Medley of pubsub improvements

[ralexstokes]

Leaving this here while I'm reviewing the current pubsub packages...

1. Don't serialize message sends, eg: https://github.com/libp2p/py-libp2p/blob/master/libp2p/pubsub/gossipsub.py#L172-L177
   Happens here and in floodsub as well -- this is a great place to use asyncio.gather

2. "separate policy from mechanism" -- in the same place, we defer to the particular router to decide who to send new msgs to... and then do the sending in the router itself. as far as i can tell, we can pull out the sending part into the Pubsub class, relying on the router for what should be its only job -- determining peers for some action

[mystical-prog]

@pacrob I would like to discuss the 1st topic in this issue, are we still considering to use asyncio.gather or should we find something equivalent in trio package now ?

[pacrob]

It looks like there was some discussion on the async topic in #174 and #383. I personally only have experience with asyncio, but it sounds like trio has been the preferred option. I haven't looked at using anyio either, but #383 implies that's the ultimate goal.

Moving forward, let's continue with the trio migration. Unless you want to dig into what using anyio would entail.

[endomorphosis]

I have been originally using asyncio on some machine learning orchestration code that I was making, I don't have enough insight into libp2p's codebase to make a value judgement, other than to say that I have been waiting for libp2p's codebase to become more mature so that I can implement it for internode communication and filesharing.

[mystical-prog]

I believe using Trio is the shared goal from our previous contributors and we should continue using it cause there is no such need as of now to migrate, I will look further into this issue keeping Trio in mind, if it's okay with everyone.