chore: don't send "haves" to unapproved peers

[EvanHahn]

This avoids leaking "have" data to unapproved peers. Most likely, this is peers with the project key that aren't in the project.

Partly addresses #268.

[EvanHahn]

I was adding a couple of new types that referenced peers. These are currently typed with any. Though I think we should use a more exact type in a followup PR, I think this makes it a little more clear and is not a regression.

[gmaclennan]

Unfortunately I think this won't work, things are more complicated...

There are many scenarios where a peer's sync capabilities are not known when two peers first connect, e.g. peer A invites peer B; peer A disconnects; peer C comes along and connects to peer B. The changes in this PR will result in peer C refusing to sync, and will require a disconnect and reconnect to fix. I

For this reason event-based updates to capabilities are needed first, so that sync can be enabled once the capability data syncs, e.g. as outlined in #268.