Selectively prune gender cache on PART and KICK

[dgw]

On PART, prune the user's cached gender only if Bucket no longer shares any channels with them.

KICK did not prune the gender cache at all before, but it now follows the same (new) logic as PART.

[dgw]

@barometz Is this kind of what you were getting at when you pointed out the gender-pruning in irc_on_quit? There it makes sense to just always clear the cache, because the user is quitting (all channels; we won't see them ever unless they JOIN again). But in irc_on_part it's possible they're only leaving one common channel, and we'll still see them in another.

[barometz]

Not really - I guess I'm asking why gender is pruned at all. I take it that's because user tracking in general doesn't persist after a user quits? From what I'm seeing in-channel, users expect gender to persist when they reconnect, as do I. Can totally see why that doesn't mesh with Bucket's concept of user tracking though.

[barometz]

OK, should've reported this better. People have been seeing the gender info getting reset at unpredictable intervals, but maybe I misunderstood the source.

[dgw]

If gender is getting lost between quit and reconnect, that's a bug somewhere else. But if you're getting reports that gender info seems to be "reset" unpredictably, that's probably #92. (tl;dr for that: join as nick1, set gender, /nick nick2, quit, then rejoin as nick1: poof, Bucket has "forgotten" nick1's gender because the database was updated with the new name on /nick.)

When a user joins, we load their set gender from the DB if it's not cached:

xkcd-Bucket/bucket.pl

Lines 2506 to 2508 in 50a9f13

	return if exists $stats{users}{genders}{lc $who};
	&load_gender($who);

When someone's gender preference is set, it's immediately stored in the cache and persisted to the database:

xkcd-Bucket/bucket.pl

Lines 1289 to 1290 in 50a9f13

	$stats{users}{genders}{lc $target} = lc $gender;
	&sql( "replace genders (nick, gender, stamp) values (?, ?, ?)",

[dgw]

Regardless of what you were originally trying to report, I'm glad it prompted me to look at the PART/KICK logic again, because those were wrong/incomplete, respectively.