I2PSnark sends interested message when not interested

[sponge]

I2PSnark sends interested message when not interested, followed by a not interested message.

While this does not break protocol, it's a waste of I2P's bandwidth, especially if the other peer unchokes and re-chokes. It also can eat upload slots on some clients disrupting the swarm from spreading pieces fairly.

[zzz]

Would you please provide additional context? Timestamped sequence of messages, perhaps? I need to know what happened before and after the two messages you describe. I don't have enough info yet to track this down. Thanks.

[zzz]

I think this is related?

<sponge> it was a great wait, but I finally have a screenshot of the I2PSnark bug that I've been attempting to explain unsuccessfully to zzz for years!
<sponge> zzz: Please see ​http://vnmf4apo3mpxitki2nzqjx24cq4ykuiptpdmihgyecomcql5ttaa.b32.i2p/files/I2PSnark-protocol-BUG.png for a screenshot of the torrent protocol bug I have been unsuccessfully attempting to explain to you all these years.
<sponge> zzz: once you fix this problem, I2PSnark *should* become as fast at downloading as Robert.
<sponge> If you rather I make a ticket with a full explaination, please let me know so that I can hand you the needed info of what is going wrong.

[sponge]

What seems to be happening is that these messages are sent when checking the piece array at the wrong time.
In order to fix the problem, here is what needs to happen.

When snark:
Completes the initial handshake set initial state to uninterested.
OR
Gets a have piece message from the peer.
OR
After a got message piece message is sent:

1: Compare peer have to local have arrays.
2: if the state has changed to interested or uninterested, send the appropriate message.

Do not send either message at any other time.