chore: refactor `ConnectionManager` for maintainability

This is a change request

Problem

We introduced a ConnectionManager a while ago to gain more control over how dials occur within a js-waku node, and slowly a lot of new APIs, refactors, etc started to bloat which is our current implementation. Our current implementation is ~580 lines, and very coupled together -- making it quite unreadable and unmaintainable.

Proposed Solutions

Split the ConnectionManager class into multiple classes, aiming to adhere to the Single Responsibility Principle.

Suggestions for the split based on the current type defs for the class:

ConnectionManager: Responsible for overall connection management, including creating instances, starting and stopping the manager, and toggling online/offline status.
PeerDialer: Handles dial of peers, including attempting dials, managing dial attempts, and processing the dial queue.
PeerHandler: can be one module or can be split into two following modules:
- PeerDiscoveryManager: Manages peer discovery events, including starting the discovery listener and dispatching discovery events.
- PeerConnectionManager: Handles peer connection and disconnection events, including starting the connection and disconnection listeners, and managing connections.
PeerInfoManager: Provides utility functions for retrieving peer information, such as tag names, configured topics, and shard info.
- Since this is more like a utility class, this can be avoided and the functions can stay part of the original ConnectionManager class being private
KeepAliveManager: Manages keep-alive functionality for connected peers. (exists already)

Notes

some inspiration here: https://github.com/libp2p/js-libp2p/tree/main/packages/libp2p/src/connection-manager

waku-org / js-waku