fix: shard lock to fix contention issue in the notify handler

[Jorropo]

I have many profiles where I had 5k+ goroutines all waiting on connectEventManager.lk while downloading.

Turns out it defer the unlock call, and call to an other function, however all of the other sub handlers all have their own locking mechanism.
So I've made it unlock first then call to the next function. (this breaks order as maybe a handler had side effect that relied on peers being handled in the same order as an other one but AFAIK this isn't a thing, all the sub handlers are fairly sane doesn't have such side effect).

I've done the same fix in engine because why not ? (as the exact same argument of consumers locking too can be made) and this completely removed it from the profile.

This patch completely removes those functions from the profile for me.

[Jorropo]

NVM tests are failing ...

[Stebalien]

Now that #565 has landed, we should look at this again. Before #565, this wouldn't have worked because we would have been able to get out-of-order notifications. However, now that we have a central event loop, we can probably get away with this?

[Jorropo]

This repository has been moved to https://github.com/ipfs/go-libipfs. There is not an easy way to transfer PRs, so if you would like to continue with this PR then please re-open it in the new repository and link to this PR.