bitswap: long-running session leaks

[Wondertan]

We've been running long-running Bitswap sessions and encountered a series of memory leaks that we've successfully identified and fixed in our fork. I plan to start upstreaming them eventually, but I am currently botted with millions of things. Anyway, I want to make you aware of their existence already in case you have the capacity to look into those.

The full branch is located here. Some of them were merged, some of them aren't. The most notable are:

• fix leak ensuring SessionInterestManager is cleaned up
• fix leak in block presence manager along with
• cleanup toFetch cidqueue
• cleanup peerresponsetracker
• rebroadcast only when there are live CIDs - not a leak, resolves issue with timer continue ticking even when there are not CIDs to rebroadcast further

All of those fixes have been tested on hundreds of nodes in production, and things have been running smoothly and steadily for 3 weeks. I am happy to answer if you start working on this sooner than when I get to opening PRs myself.

cc @hsanjuan, @gammazero, @lidel

[gammazero]

I will create separate PR for each of these and review and merge these into our code base, unless you would rather do this from your fork. We are also resolving memory consumption issues with connections, so it would be great to get all the known memory issues handled in at the same time. So let me know soon.

Thank you.

[gammazero]

The first two fixes appear to be incorrect according to the comment in SessionInterestManager:

		// Note that once the block is received the session no longer wants
		// the block, but still wants to receive messages from peers who have
		// the block as they may have other blocks the session is interested in.

@Wondertan Please let me know if this needs further investigation.

[gammazero]

See the following PRs:

• Fix leak due to cid queue never getting cleaned up #756
• Remove peer's count of first responses when peer becomes unavailable #757
• Do not reset the broadcast timer if there are no wants #758
• Remove want-block sent tracking from sessionWantSender #759

[github-actions]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[Wondertan]

Hey @gammazero, thank you for submitting the fixes.

The first two fixes appear to be incorrect according to the comment in SessionInterestManager:

Re above. The first commit cleans up the SessionInterestManager, otherwise its only cleaned when the session is closed. I don't think that this behavior is correct, even though it might be expected, as per comment you referenced. However, I also don't see my fix contradict to the comment. It says "but still wants to receive messages from peers who have the block as they may have other blocks the session is interested in". Why would cleaning up SessionInterestManager prevent receiving new messages from the peers? It also states other blocks, while we clean particular blocks.

[Wondertan]

6cd1ed9 goes further and cleans up BlockPresenceManager, but specifically for CIDs that are not in interest for any other session. There is no reason to keep CID presence information from peers when the CID has already been processed and no other session needs it.

[Wondertan]

And 70a6503 is pretty severe bug independently of long-running sessions. Check the comment there for description. Besides, one could blow up a peer by sending presences of completely arbitrary CIDs, because Bitswap never checks if those CIDs presences are even relevant(in SIM) and directly stores them. This commit fixes that