Make SERVER_BUSY more generic

[martinthomson]

This is spawned from #3690 and #3704.

The discussion there revealed that SERVER_BUSY has implied semantics that aren't helpful and it would be better to have a more generic message instead.

This tracks that. The resolution might be #3704, depending on how we resolve this.

[martinthomson]

My personal preference is to not merge #3704. A generic error code is more useful.

There is a small loss here in that a server has to use a non-intuitive code for the case that it finds it can't continue with a connection due to load, but I am comfortable with that.

[MikeBishop]

#3694 was already merged, and there's some question about whether it was actually editorial. This issue tracks the question retroactively. The proposal here is to leave #3694 merged / close #3704. The alternative is to merge #3704, reverting the other PR.

[janaiyengar]

I prefer the generic message, so I would like to see the current state of affairs retained. That is,

• use CONNECTION_REFUSED going forward (instead of SERVER_BUSY), and
• do not merge Revert "rename SERVER_BUSY to CONNECTION_REFUSED" #3704.

If there is a need for other more specific error codes, we can deal with that separately.

[mjoras]

+1 to leaving the current state. CONNECTION_REFUSED is generic enough to be useful in the situation @marten-seemann described, and while it's nice to have more specific error codes, I don't think there's an abundant need for a BUSY-like signal, without also getting into the business of prescribing things like time-based retry for QUIC clients.

[kazuho]

+1 to retaining the current state.

I'm repeating my comment on #3694, but when QUIC is used as the only transport protocol (rather than with happy-eyeballing), it has to be resilient to MITM attacks as TLS over TCP is.

TLS over TCP does not have an unauthenticated error code that tells the client to stop trying to connecting to the server. We cannot have such thing in QUIC, because if we do, QUIC becomes more prone to MITM attacker than TLS over TCP is.

CONNECTION_REFUSED is fine in this respect, because it does not indicate to the client what the reason was. But error codes like SERVER_BUSY or TRY_LATER would have the implications that we cannot have.

[martinthomson]

Closing as proposed.