feat: Add options to broadcast Peer info on seeing a new subscription

[justin0mcateer]

The existing options allow only for publishing the current Peer's info on a fixed interval, and once automatically at start up. However, when a new peer joins which is also participating in the PubSub Peer Discovery process, it has to wait until the next interval to receive notification of existing peers. This creates an unnecessary trade-off between a low broadcast interval (causing lots of chattiness) or a long delay until peer discovery.

The PubSub interface provides the ability to see when new peers have subscribed to various topics. This patch adds a very small amount of optional logic to broadcast our peer info reactively when we see new peers on the topic. The default configuration is to disable this functionality unless the user specifically opts in.

Also, if there were a large number of peers participating in the PubSub Peer Discovery process, having them all broadcast their peer details in synchronization would create somewhat of a 'thundering herd' problem. Therefore, I have included a configurable randomized delay for this reactive broadcast. By default it is a fraction of the broadcast 'interval', but can be configured as desired.

[achingbrain]

Just thinking more about the logic here - it all runs off the subscription-change pubsub event. We receive peer subscriptions and generate this event when they send an RPC message to us, which means we have a connection to that peer.

If we have a connection then the identify protocol will run around the same time, so using the subscription change event to trigger a broadcast of our peer info to all connected peers seems like it might create a burst of traffic for no reason, since we're sending our data to peers that already have it.

Our data might later get gossiped to peers further away but it's questionable if this is desirable since you may end up discovering the entire network which could be arbitrarily large.

I guess instead of broadcasting you could try to figure out a mechanism to only send your data to the newly connected peer, but this is basically the identify protocol.

Identify is what drives network topologies - if you are using this discovery mechanism to discover peers in the hope that they speak a certain protocol, you may be better off registering a topology listener instead?

[justin0mcateer]

This particular sevice by definition broadcasts peer identities to the entire network. The change here only has to do with the timing of those broadcasts.

We use this service in relatively small private networks to discover peers as they come online.

[achingbrain]

The change here only has to do with the timing of those broadcasts.

It's more than that - the subscription-change event fires when a single peer changes its subscription list and the handler in this PR causes the current node to broadcast its peer info to every peer in the network.

If the peer that changes its list is connected to 50 nodes, then 50 messages will get sent to every node in the network. If it's 10 peers that come online and connect to those 50 nodes and send their subscription list, 500 messages will get sent to every node in the network.

Backoff/debounce helps here a bit but it's hard to know what the ideal delay would be - if it approaches the existing interval you might be better off just using that.