reevaluate "insecure reattach" error

[slingamn]

See #955 for some context. Bouncer reattach that mixes secure and insecure connections has been disallowed ever since the functionality was first built (in c2faeed). The following year (998ac69) we removed the plaintext listener by default.

Ever since, it seems like most errors due to mixing secure and insecure connections are spurious: the connection is actually secure, but is being transported over an incorrectly configured reverse proxy (e.g. WEBIRC is being sent without the secure flag, or a websocket is being proxied without adding X-Forwarded-Proto: https). It may be time to delete this check; we are already pushing operators hard to disable plaintext, and it's not clear what purpose it serves if plaintext is enabled nonetheless (the SASL PLAIN handshake is still being transmitted and acknowledged in plaintext, we just don't allow the reattach).

[slingamn]

Question: should we be trying to prevent clients from mixing Tor and non-Tor? (I thought we were already doing this, but we are not, so it would be a compatibility break.)

[Mikaela]

Question: should we be trying to prevent clients from mixing Tor and non-Tor? (I thought we were already doing this, but we are not, so it would be a compatibility break.)

No. That will mess up people like me who are just using Tor to provide cover traffic for those actually depending on Tor (or just attempting to normalise its use) and harm especially iOS users.

Additionally it will hurt at least one network I oper on as I don't need anonymity or privacy from myself while using Tor to connect there lets me know if we have an issue with the Tor node or otherwise helps with troubleshooting if someone asks about it or claims it to not be working.