Ensure channel.users is an accurate representation of the NAMES response after updating by removing stale users

[f0x52]

https://github.com/matrix-org/node-irc/blob/master/src/irc.ts#L660
When parsing responses to the NAMES command, (changes to) users are only ever set on the channel.users Map. This causes the channel.users list to perpetually keep growing as new users join, but never remove entries from users that have since left.

onPart() does remove entries, which works most of the time, but it seems these can be missed, most likely due to netsplits.

This fix keeps a separate Map (tmpUsers) where usernames + modes are stored as they come in through onReplyName(). In onReplyNameEnd() the old userlist is cleared, the new entries are copied over (so only the users in the NAMES response remain), and the tmpUsers Map is cleared so it can be used for the next NAMES block.

Found this while debugging why the Matrix side of many bridged rooms has many more IRC users than the IRC side.

[f0x52]

Signed-off-by: f0x [email protected]

[f0x52]

Hmm while trying to yarn link this into matrix-appservice-irc, I'm wondering if it might be better to store the temporary user Map somewhere else, probably doesn't make as much sense to flush it to storage, or even expose it to consumers.

[f0x52]

Alternative approach master...f0x52:clear-names-internal

[progval]

onPart() does remove entries, which works most of the time, but it seems these can be missed, most likely due to netsplits.

That would be a bug in node-irc too. Servers reliably inform clients of every other user who leaves, with a QUIT message.

[f0x52]

Right, it's been difficult to fully debug why this happens, as it does so over time, on production bridges..

I think it might instead be caused by the Client getting reused across connections, so it's missing PART/QUITS while it's offline, and continues to use that older users list

[progval]

If that's the case, then this PR is the right fix. Let's see if it fixes (or reduces) the issue once it's merge