QUIC: ignore duplicate PATH_CHALLENGE frames. According to RFC 9000, an endpoint SHOULD NOT send multiple PATH_CHALLENGE frames in a single packet. The change adds a check to enforce this claim to optimize server behavior. Previously each PATH_CHALLENGE always resulted in a single response datagram being sent to client. The effect of this was however limited by QUIC flood protection. Also, PATH_CHALLENGE is explicitly disabled in Initial and Handshake levels, see RFC 9000, Table 3. However, technically it may be sent by client in 0-RTT over a new path without actual migration, even though the migration itself is prohibited during handshake. This allows client to coalesce multiple 0-RTT packets each carrying a PATH_CHALLENGE and end up with multiple PATH_CHALLENGEs per datagram. This again leads to suboptimal behavior, see above. Since the purpose of sending PATH_CHALLENGE frames in 0-RTT is unclear, these frames are now only allowed in 1-RTT. For 0-RTT they are silently ignored.

--- a/src/event/quic/ngx_event_quic_migration.c
+++ b/src/event/quic/ngx_event_quic_migration.c
@@ -40,6 +40,14 @@ ngx_quic_handle_path_challenge_frame(ngx
     ngx_quic_frame_t        frame, *fp;
     ngx_quic_connection_t  *qc;
 
+    if (pkt->level != ssl_encryption_application || pkt->path_challenged) {
+        ngx_log_debug0(NGX_LOG_DEBUG_EVENT, c->log, 0,
+                       "quic ignoring PATH_CHALLENGE");
+        return NGX_OK;
+    }
+
+    pkt->path_challenged = 1;
+
     qc = ngx_quic_get_connection(c);
 
     ngx_memzero(&frame, sizeof(ngx_quic_frame_t));

--- a/src/event/quic/ngx_event_quic_transport.h
+++ b/src/event/quic/ngx_event_quic_transport.h
@@ -336,6 +336,7 @@ typedef struct {
     unsigned                                    retried:1;
     unsigned                                    first:1;
     unsigned                                    rebound:1;
+    unsigned                                    path_challenged:1;
 } ngx_quic_header_t;