Allow prioritization of traffic per topic

[whyrusleeping]

I'd like to be able to prioritize traffic on one topic over traffic from another, so that messages from topic B would never cause delays (as much as is practical) for topic A, if topic A hash higher priority.

[aschmahmann]

On the whole seems reasonable. However, I suspect that without having a similar type of application priority at lower levels of the libp2p stack you're frequently not going to get the results you want unless pubsub is really the only data exchange protocol you're running.

For example, I can prioritize topic A over B, but other libp2p functions (e.g. bitswap/graphsync) may still end up getting in the way.

[raulk]

On the sending side, gossipsub coalesces pubsub messages (on the same or different topics) that are directed to the same peer within one aggregate protobuf wire message (which also contains the gossip, and subscription changes). Topic-centric priorities don’t seem like they’d make any difference in that scheme.

Perhaps on the receiving side we could process messages and gossip for multiple topics by descending order of priority (calling subscribers and propagating), but this sounds a bit like premature optimisation at this point — unless we have evidence to back this choice.

[Stebalien]

We can do this at two points:

1. When sending a message, we can replace the single sendMsg channel with high, medium, and low priority channels.
2. When validating messages, we can replace the single `validateQ with high, medium, and low priority channels.
3. When joining a topic, we can specify the priority.

This should handle the two bottlenecks: validation and sending.