(re)investigate gauging peer disconnections with js-waku

[danisharora099]

Problem

There have been attempts in gauging peer disconnections properly through peer:disconnect event listeners and the IPFS ping protocol.
Some of the efforts are tracked here: #1189

Proposed Solutions

Understand how different events are emitted in context to disconnections.

With the release of libp2p 0.45.x, it might be worth it to attempt the investigation keeping in consideration the connection:close and peer:disconnect handlers exposed: https://github.com/libp2p/js-libp2p/blob/70fe699c424c22f81e39c47631fda73abc1cae9e/doc/migrations/v0.44-v0.45.md?plain=1#L143

Notes

• should be attempted once the js-waku upgrade to libp2p 0.45.x is merged/released: feat!: upgrade to [email protected] #1400

[danisharora099]

Blocked by libp2p/js-libp2p#1904 and #1415

[weboko]

Shouldn't be blocked anymore?

[danisharora099]

upon further investigation and taking into context previous findings, it's safe to conclude:

• connection:close: monitor a permanent connection close between the local & remote node (which should usually be triggered along with peer:disconnect for cases where we only have one connection with the remote node)
• peer:disconnect: monitor permanent disconnections with peers (this would imply not that no the underlying connection(s) have been permanently closed, and the only way to communicate with this peer again is to open a new connection/reconnect)
• pings will fail when there are temporary network degradations or reachability issues. this does not mean that the underlying connection has been closed.