auth bypass via REGISTER command

[slingamn]

This appears to originate in 9ed789f, but wasn't caught until @ajaspers reported it today. So the affected releases are 2.4.0, 2.5.0, 2.5.1, and 2.6.0. It is fixed in 2.6.1 and master.

The main vulnerability here is for configurations that enable server.password (not a default) and leave accounts.registration.allow-before-connect enabled (a default). From there, there are four potential configurations:

1. login-via-pass-command=true, skip-server-password=false (these are the defaults). This configuration is disallowed and fails with the error: Using a server password and login-via-pass-command requires skip-server-password as well
2. login-via-pass-command=true, skip-server-password=true (i.e., setting skip-server-password to true). This allows an authentication bypass via the REGISTER command (which is allowed before connection registration).
3. login-via-pass-command=false, skip-server-password=false (i.e., setting login-via-pass-command to false). This does not allow an authentication bypass, but allows unauthenticated users to reserve account names via the REGISTER command, which is a lesser vulnerability
4. login-via-pass-command=false, skip-server-password=true (i.e., changing both of the default values for these fields); this is an authentication bypass as in case 2.

There is a secondary issue around documenting the interactions between allow-before-connect and require-sasl. This is described in more detail in the changelog:

Private servers that use accounts.require-sasl for protection. If these servers do not additionally set accounts.registration.enabled to false, the REGISTER command can potentially be used to bypass authentication. Affected operators should set accounts.registration.enabled to false; this recommendation appeared in the operator manual but was not emphasized sufficiently. (Configurations that require SASL but allow open registration are potentially valid, e.g., in the case of public servers that require everyone to use a registered account; accordingly, Oragono 2.6.1 continues to permit such configurations.)