Refactor : Peer Store

[chaitanyaprem]

Issue

This issue will be used to track the refactor and various improvements pertaining to peer store. Peer and connection managment related enhancements are being tracked by #594.

As the objectives of go-waku are different from nwaku and js-waku, changes required would be identified by
going through the improvements done in nwaku and js-waku along with study on improvements specific to go-waku.

Following are the list of items/considerations for the refactor.

Some high level thoughts for consideration

1. Persisting peers - Implement persistent peer-store, and remove dependency from libp2p peer-store due to this. Establish connections from persisted peers during initialization, only use discover if not enough peers are available.
2. Limit peerStorage capacity similar to - feat(networking): prune peers from peerstore exceeding capacity nwaku#1513
3. Review Peer related metrics and useful reporting and see if any enhancements are required.
4. Usage specific behaviours (what kind of config to be provided to user layers in order to tune the peer management) Considering service node and light client usage of go-waku - To be analyzed

[chaitanyaprem]

As per discussion here, waku has a special case where each time a wakunode is restarted or in status desktop case a user logs out and logs in a new peerID is generated which can bloat up peerStore.

For now a workaround has been implemented which is not clean.

Taking a look at Prysm, noticed that they don't use libp2p peerStore at all and have their own peerStore defined.
We should also take this approach as Waku's dynamically changing peerID concept doesn't go well with the way libp2p peerstore is implemented.

[chair28980]

Review issue's status in January '24.

[chair28980]

Add to Doha agenda for review.

[chaitanyaprem]

Refer #852 as well during discussion

[chaitanyaprem]

This would no longer be required as nwaku would be replacing go-waku in status by end of 2024.
Hence closing this as there is no plan to implement it.