[identify] Add configurable automatic push on listen addr changes.

[romanb]

This PR picks up a suggestion of @mxinden from #1999 (review). When a new or expired listen address is reported by the Swarm, it can result in an active push of an identify message to all connected peers. Two points worth noting:

1. I've made this behaviour configurable and disabled it by default. I think that having such new features opt-in initially avoids surprises and allows selective experimentation in a more controlled manner. Also, since listen addresses are often not directly reachable due to NAT, it may be better if it is selectively enabled for those nodes who are known to be deployed with publicly reachable listen addresses. Lastly, if there are potentially a lot of connected peers, this kind of active push may cause quite a traffic burst. If it proves beneficial over time without any downsides, it can still be made the default later. However, I generally think that active pushes are more likely to be useful if they are targeted to specific subsets of peers.
2. I have not included inject_new_external_addr as a trigger for an automatic push. I am somewhat concerned that, given that these addresses are reported by remote peers, it would make it too easy to remotely make a node spam all its connected peers with messages, possibly even with invalid data, since this would essentially provide a remote trigger for a kind of broadcast. One could of course add defensive measures via some form of throttling, but at least a naive implementation, as I've done here for inject_new_listen_addr and inject_expired_listen_addr, seems to be too easy to abuse.

[mxinden]

Thanks for the follow up pull request.

I've made this behaviour configurable and disabled it by default. I think that having such new features opt-in initially avoids surprises and allows selective experimentation in a more controlled manner. Also, since listen addresses are often not directly reachable due to NAT, it may be better if it is selectively enabled for those nodes who are known to be deployed with publicly reachable listen addresses. Lastly, if there are potentially a lot of connected peers, this kind of active push may cause quite a traffic burst. If it proves beneficial over time without any downsides, it can still be made the default later. However, I generally think that active pushes are more likely to be useful if they are targeted to specific subsets of peers.

Disabling by default at first and maybe enabling by default in future releases sounds good to me.

I have not included inject_new_external_addr as a trigger for an automatic push. I am somewhat concerned that, given that these addresses are reported by remote peers, it would make it too easy to remotely make a node spam all its connected peers with messages, possibly even with invalid data, since this would essentially provide a remote trigger for a kind of broadcast. One could of course add defensive measures via some form of throttling, but at least a naive implementation, as I've done here for inject_new_listen_addr and inject_expired_listen_addr, seems to be too easy to abuse.

Good point. I did not consider this attack vector in my initial proposal. While in the benign case, pushing of externally observed addresses would likely be most useful, I agree that it is not worth the attack surface. In case people still need it, I would be open to discussing some kind of throttling mechanism.