RPC: Make very sure that early errors cause connections to be closed

There's an attack category where somebody tricks a web browser or something into talking to an RPC port, and then sends "authentication" to that port via a POST request.

For Tor in particular, the attack would POST a request to the control port containing something like

AUTHENTICATE
SETCONF DisableAllSecurityFeatures=1

To prevent this attack, Tor deprecated empty AUTHENTICATE messages over TCP, and declared that any unrecognized pre-authentication message (for example, "HTTP/1.1 POST...") would cause the connection to be closed.

---

Now, this attack shouldn't be viable with Arti's RPC design, since session IDs are unpredictable, and since there is no auth method that over TCP without having to read a file.

Nonetheless, as a defense in depth, rpc-meta-draft says:

Taking a lesson from Tor's control port: we always want a correct authentication handshake to complete before we allow any requests to be handled, even if the stream itself is such that no authentication should be requires. This helps prevent cross-protocol attacks in cases where things are misconfigured.

We should make sure that this is implemented in arti-rpcserver, and implement a test for it.