Should a `NetworkBehavior` be informed about a dropped `ToSwarm::NotifyHandler` event?

Description

Behaviors can send events to a connection handler by emitting a ToSwarm::NotifyHandler event.
Depending on the PendingNotifyHandler::{One(_), Any(_)} parameter, the swarm will then select either one specific, or any connection handler, that will receive the event.

If the connection has closed in the mean time (either the one specific that is targeted, or all connections), the event gets silently discarded.

@jxs and I had a brief out-of-band discussion that we might want to inform the behavior about the event being dropped.

However, thinking about it now, I am not sure if the behavior even needs that info.
As already mentioned, the event is only dropped if the connection closed. The behavior is being informed about connections closing. So behaviors like request-response can simply track pending events for each connection, and based on that infer that a pending event/ request is discarded.
That must be done anyway because it could be that the handler already consumed the event and then the connection closes.

@jxs is there a specific case where it's still problematic that the NotifyHandler event is silently dropped? And if so, how does that differ from the second scenario that I described, where the connection closes after the handler consumed the event?

Start by tracing NetworkBehavior handling of ToSwarm::NotifyHandler and PendingNotifyHandler::{One, Any} through connection-close processing. Compare dropped events with events consumed before a connection closes, using the existing behavior and handler lifecycle paths mentioned in the issue. Done requires a decided outcome for whether behaviors receive notification and an agreed implementation scope.