Immediate close without state

[martinthomson]

In some cases, we allow CONNECTION_CLOSE (or immediate close) to be used when there is no state for the associated "connection". Most notably, this happens when a server receives a bogus Initial from a client (see #3269 for the prime example).

Immediate close works fine for those cases, except that it mandates the creation of state: the timer that runs for the closing period and maybe a packet. That doesn't make sense, because what you want prior to establishing ANY state is to just send the signal without creating any state.

So, we should allow an exception for immediate close where there is no connection state. This requires a little finesse as it touches on DoS concerns. An (unauthenticated) Initial packet might is handled statelessly with the resulting CONNECTION_CLOSE causing the client to kill state. If the server wanted to keep that state, that might be bad. For that, there is no perfect answer, because it trades off feedback about errors against a very narrow form of denial of service that we agreed we wouldn't take special steps to protect against. So we should just explain the trade-off and let the servers decide what to do.

#3292 fixes this one.