Bridge roster/topology changes to addRemovePeers

When address book changes, we need to set up new connections and tear down some of the old ones. We need to compare old and rosters (possibly including topology) and decide what changes should be requested from network layer.
To additionally complicate things, we cannot do those changes immediately after receiving future roster. We probably need to preserve old connections until old roster becomes stale/ancient and create new connections early, to avoid delays on roster change round. This delayed diff logic needs to be wired between roster change notifications, round changes and network.
Additionally, all downstream components should be hardened against received messages from nodes which have no business of being in current roster (because it has not happened yet, or because it is already obsolete, but not yet fully purged), but this is not in scope of this task.

Start by tracing roster change notifications, round changes, and the network layer's addRemovePeers flow. Determine how old and future rosters or topology are represented, then define and wire delayed connection changes so old connections persist until the old roster is stale while new connections are created early; downstream message hardening is explicitly out of scope.

Written by the indexing model from the issue text.