Connectivity::Connection_closed application trigger type is confusing

[LPardue]

ConnectivityConnectionClosed = {

    ; which side closed the connection
    ? owner: Owner
    ? connection_code: TransportError /
                       CryptoError /
                       uint32
    ? application_code: $ApplicationError /
                        uint32
    ? internal_code: uint32
    ? reason: text
    ? trigger:
        "clean" /
        "handshake_timeout" /
        "idle_timeout" /
        ; this is called the "immediate close" in the QUIC RFC
        "error" /
        "stateless_reset" /
        "version_mismatch" /
        ; for example HTTP/3's GOAWAY frame
        "application"
}

GOAWAY doesn't close the connection, so I find this example a bit confusing.

In quiche, I would be able to close a connection using transport or an application CONNECTION_CLOSE and log that information in the other fields like connection_code etc.

Maybe we should remove that trigger variant?

[rmarx]

I see the confusion. I think the intent was to make a difference between e.g., a programmer-triggered close on the QUIC level ("clean") vs a GOAWAY triggered one at the application level. Even though the GOAWAY doesn't immediately trigger the close directly, it was the conceptual "trigger" that led to the connection being closed down. Of course, you can make an argument that stacks won't track this and will not log this, and I can follow that :)

I was also thinking of non-HTTP3 stuff running over QUIC however that might have application-level direct-close things (especially at the side initiating the close of course), so I wouldn't just do away with application here. Maybe just remove the comment?