investigate/fix handling of `MODE -k`

[slingamn]

Previous discussion on #408. Currently, Oragono treats k (channel key) as a "type C mode"; it has a parameter when being set, and not when being unset. However, ircd-seven and inspircd consider it a type B mode (requires a parameter when being set or unset), which seems supported by the examples in RFC2812.

Here's the freenode behavior:

mode #test_32487 +k beer
:asdfkj324587234!~a@2607::1 MODE #test_32487 +k beer
mode #test_32487 -k
:asdfkj324587234!~a@2607::1 MODE #test_32487 -k *

[DanielOaks]

(I seem to recall this being different between diff ircds... the old stats data seems to suggest I'm misremembering tho. regardless, would be good to dig into it a liiiittle more to confirm and make sure no major ircds treat it as a type C

[slingamn]

Current oragono behavior is Postel-y (concerns about ambiguity notwithstanding):

<< MODE #ineverfuckjr +k beer
>> @time=2020-03-18T11:40:57.769Z :shivaram!~shivaram@darwin.network MODE #INeverFuckJR +k beer
<< MODE #ineverfuckjr -k beer
>> @time=2020-03-18T11:41:05.468Z :shivaram!~shivaram@darwin.network MODE #INeverFuckJR -k
<< MODE #ineverfuckjr +k beer
>> @time=2020-03-18T11:41:10.812Z :shivaram!~shivaram@darwin.network MODE #INeverFuckJR +k beer
<< MODE #ineverfuckjr -k
>> @time=2020-03-18T11:41:14.908Z :shivaram!~shivaram@darwin.network MODE #INeverFuckJR -k

[slingamn]

inspircd rejects -k with no argument and even validates the argument (if you supply the wrong key, it's a no-op). This seems excessive!

I like the freenode behavior.

[DanielOaks]

Makes sense, yeah let's go with the fn behaviour