PubSub Discovery boostrapping does not return as fast as it could

Nobody has claimed this yet.

Currently when we Publish to a topic and require boostrapping (e.g. passing in `WithReadiness(MinTopicSize(5))`) we wait until a discovery query completes before checking again to see if we're ready.

https://github.com/libp2p/go-libp2p-pubsub/blob/534fe2f382d8dd75dab89ddb0760542546c9f24e/discovery.go#L268-L274

This is not ideal since it's possible that we could passively discover peers (MDNS, another protocol causing a connection, etc.) during a long discovery process.

Some options:
1. Periodically check the "ready" condition instead
- There's a balance between how quickly we return and performance. The more frequently we poll, the faster we return and the more resources we consume. A backoff layer could help here, but that's just more complexity
2. Use our internal peer discovery events and check every time we get a new peer
- Assumes that the "ready" condition is static (e.g. find 5 peers), if the condition is dynamic then the events won't help us

@vyzo any thoughts here?

Start at discovery.go lines 268-274 and trace how Publish readiness with MinTopicSize(5) waits for discovery queries. Compare periodic readiness checks with internal peer-discovery events, then define and test behavior showing that passively discovered peers can satisfy readiness without waiting for the query to complete.

Written by the indexing model from the issue text.