Address Book POC implementation

[jm-clius]

This PR closes #498

It introduces a POC version of a Peer Store with Address Book, based on similar implementations in go and js.

The POC:

• Implements a simple AddressBook API to add, get, set and delete multiaddresses for peers
• Implements a simple PeerStore API to get and delete stored information for peers across all books (although the address book is the only one implemented so far)
• Allows clients to add their own listeners to be notified of peer store events. Each listener contains a number of handlers that are triggered on changes in the peer store. For POC purposes, I have only added a handler for multiaddr changes on a peer.

Suggested next steps:

1. Gain consensus both on general approach of using a Peer Store and specifics of implementation (e.g. how listeners work, API usability, etc.)
2. Implement KeyBook, ProtoBook and rudimentary MetadataBook (likely in this order)
3. POC integration of Peer Store(s) in other modules. WakuRelay is a possible candidate here to implement a local Peer Store until it's fully integrated elsewhere in nim-libp2p
4. TBD integration of a peer store in nim-libp2p (e.g. by building a peer manager, discovery interface, etc.)

[dryajov]

Unless you're planning on passing listeners as an argument you probably don't need a ref here.

[jm-clius]

Thanks, make sense. Fixed in 29dcc33.

[dryajov]

just to reiterate, you don't need a ref.

[jm-clius]

Fixed in 29dcc33.

[oskarth]

Semantic wise looks reasonable to me! I'll defer to @dryajov re nim-libp2p specifics.

[oskarth]

Is this communicating change per se (as in a delta) or is the set here the sum of all, existing and new, multiaddresses?

[jm-clius]

Ah, yes, this could have been clearer. It's not merely the delta, but communicates all known multiaddrs per peer whenever there's a change as per js-implementation.

[codecov]

Codecov Report

Merging #499 (29dcc33) into master (b2ea5a3) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #499      +/-   ##
==========================================
- Coverage   86.23%   86.19%   -0.04%     
==========================================
  Files          49       49              
  Lines       11672    11672              
==========================================
- Hits        10065    10061       -4     
- Misses       1607     1611       +4     

Impacted Files	Coverage Δ
libp2p/protocols/pubsub/gossipsub.nim	78.41% <0.00%> (-0.72%)	⬇️
libp2p/crypto/rsa.nim	86.57% <0.00%> (+0.22%)	⬆️

[jm-clius]

@dryajov any further changes from your side, or can this be merged?

[dryajov]

Not sure if we need an object to encapsulate the event's callback, it doesn't cary any additional information and can be easily added as parameter to the callback later on.

[jm-clius]

Ah, sorry, I somehow missed this comment.

I see your point. The encapsulating "listener" was created to hold all event handlers that may be defined for other books (keyChange, protoChange, etc.) so that the Peer Store wouldn't need a separate collection for each type of handler. Can easily change to such an implementation though.

(Going to merge this for now to unstable and address this in future PR once more books are added.)

[dryajov]

@jm-clius I think this looks close enough to what's in js and go and I think this is a good start. I would not merge it to master right now tho and instead I will create an unstable branch where all new features/development should happen first - master should remain stable and only get hotfixes and stable features. Please hold off on merging for now I'll do that once I create the unstable branch.

[dryajov]

@jm-clius I've added an unstable branch, please repoint this PR there.