Emit events when new CIDs are available

Connection::open_path can fails if there are no remove CIDs for the path. There is nothing the application can do about this, it normally resolves itself after a little while once CIDs arrive.

However the application is never told when new CIDs are available. Iroh currently works around this by waiting some arbitrary (long) time before trying again, which is not ideal.

If we added a PathEvent::NewCids { path_id: PathId } then it would be possible for the application to react and try again.

One challenge is that new CIDs often come in batches, but that the application only needs the event once per batch. This problem already exists with the events emitted by Connection::nat_traversal_updates. Another issue with the batches is that the events queue is bounded, so if a lot of new CIDs arrive other events in the queue will be pushed out. So it is kind of important to debounce on the emitting side. Or maybe events are the wrong mechanism for this entirely.

A watcher-style API might be an option. But needing to have each path ID means it needs to be a set or similar, and collections are not very suitable for watchers. If it is a watcher it might have to be expressed as the set of all paths which currently have CIDs, or something similar.

Start by reading Connection::open_path and the existing PathEvent handling, then compare the batching behavior of Connection::nat_traversal_updates and the bounded events queue. Determine whether a debounced NewCids event or watcher-style API fits better. Done means applications can react when CIDs arrive for a path without repeated events or displacing unrelated queued events.