feat(identify)!: report what we pushed to a remote peer

[dhuseby]

Description

Starting in #3980, we make more use of the identify push protocol by actively notifying the peer when our locally supported protocols change. We emit an event (Pushed) to the user in that case. This event however does not include what we pushed.

Users might be interested in the internal changes that we push to remote peers. This patch adds the identify Info to the Pushed variant.

Fixes #4332.

Notes & open questions

None

Change checklist

• I have performed a self-review of my own code
• Discuss this speculative pull request in the issue
• I have made corresponding changes to the documentation
• Fix all of the borked tests
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

I am not convinced that it is the responsibility of the identify protocol to emit this event. Every protocol has access to this information, why should identify specifically report this in this events? It has nothing to do with identify per-se. As suggested in #4332 (comment), we could extend the Pushed variant with the information that was pushed.

The fact that the user received a Pushed variant tells them that something changed and we actively notified our peers. It may have been an address or the set of protocols. We could also model in more detail what exactly we pushed, i.e. have a "reason" of some sorts like:

Pushed {
	peer: PeerId,
    info: Info,
    trigger: WhatChanged
}

enum WhatChanged {
   LocalProtocols,
   ExternalAddresses
}

This starts to get a bit involved though. As a first step, we could simply include Info and leave it up to the user to diff them. Thoughts?

[dhuseby]

This starts to get a bit involved though. As a first step, we could simply include Info and leave it up to the user to diff them.

This suggestion makes a lot of sense. Let me change my PR to be this.

[mergify]

This pull request has merge conflicts. Could you please resolve them @dhuseby? 🙏

[thomaseizinger]

Thanks @dhuseby !

A few minor comments :)

[thomaseizinger]

Is it guaranteed that this is actually the info we pushed? What if our state changed since we sent it to the other peer?

I'd prefer if we changed the OutboundUpgrade implementation such that it emits the Info that it sent over the wire so we can carry it forward here.

[thomaseizinger]

Marking this as draft because it is a breaking change.

[dhuseby]

Closing this broken PR (no force push!) and replacing with #4527