fix a fairly bad bug where nicks could get out of sync
during nick change, removeInternal(client) was being called even before checking
whether the new nick was in use or reserved. Reproduction steps:
1. Log in a client 'alice'
2. Log in a client 'bob'
3. bob issues /nick alice, which fails (correctly) with:
:oragono.test 433 bob alice :Nickname is already in use
4. alice issues /msg bob hi, which fails (incorrectly) with:
:oragono.test 401 alice bob :No such nick
1. Remove leaveClientIdle (unused)
2. s/leaveClientActive/leaveClientIdle/
3. make ISON a leaveClientIdle command (some clients send it periodically
if a /msg window is left open)
* fix a race condition: a call to `Write` does not spawn a writer goroutine
if the trylock is held, so `BlockingWrite` must check for fresh data after
releasing the trylock
* streamline some close/finalize logic
1. Handle PROXY lines with IPv6 addresses starting with ::
(similar to WEBIRC in issue #211)
2. Strip v6 mapping from v4 addresses when handling proxied IPs.
According to https://defs.ircdocs.horse/defs/numerics.html, 330 RPL_WHOISACCOUNT
takes 4 parameters: `<client> <nick> <authname> :<info>`. We were omitting
the second parameter (the target nick).
Also refactor locking.
Previously, we generated and prepended a long salt before generating
password hashes. This resulted in the hash verification cutting off long
before it should do. This form of salting is also not necessary with
bcrypt as it's provided by the password hashing and verification
functions themselves, so totally rip it out.
This commit also adds the functionality for the server to automagically
upgrade users to use the new hashing system, which means better
security and more assurance that people can't bruteforce passwords.
No need to apply a database upgrade to do this, whoo! \o/