Reject empty NEW_TOKEN frames with FRAME_ENCODING_ERROR

[rootkiller6788]

Summary

RFC 9000 Section 19.7 requires the Token field in a NEW_TOKEN frame to be non-empty, and a client MUST treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR.

quiche currently parses an empty token successfully and delivers it to the connection visitor, leaving the connection open (the token is later silently ignored by the TLS handshaker).

Change

In QuicFramer::ProcessIetfFrameData, after ProcessNewTokenFrame succeeds, reject an empty token with QUIC_INVALID_FRAME_DATA, which maps to FRAME_ENCODING_ERROR on the wire (see QuicErrorCodeToTransportErrorCode).

Tests

• Added QuicFramerTest.NewTokenFrameEmptyToken, which verifies a NEW_TOKEN frame with a zero-length Token is rejected with QUIC_INVALID_FRAME_DATA.
• Updated NewTokenFrameInstigateAcks, ServerClosesConnectionOnNewTokenFrame, and AckElicitingFrames to use a non-empty token, since an empty token is now correctly rejected before reaching QuicConnection::OnNewTokenFrame.

The server's own NEW_TOKEN send path (QuicSession::SendNewToken) always writes a non-empty token (it prepends a kAddressTokenPrefix byte and returns early if the address token is empty), so this change does not affect the legitimate send path.

Closes #135 (and the duplicate #133).

[rootkiller6788]

Hello, I've addressed the current merge state by syncing this branch with the latest upstream main. The branch had fallen behind main (the PR was based on 0a6b55f, while main has since advanced). I merged the current main into reject-empty-new-token and it came in cleanly with no conflicts. The PR diff is unchanged in substance: it still contains exactly the empty-token rejection in QuicFramer::ProcessIetfFrameData plus the corresponding test updates in quic_framer_test.cc and quic_connection_test.cc. For reference, the checks that run for external-contributor PRs — check-changes (GitHub Actions Scan) and cla/google — are all green. The remaining required status appears to be Google's internal presubmit, which I believe can only be triggered by a maintainer; if so, could you please take a look and run it when convenient? No behavior beyond the original fix has changed: a NEW_TOKEN frame with an empty Token field is now rejected with QUIC_INVALID_FRAME_DATA (mapped to FRAME_ENCODING_ERROR on the wire, per RFC 9000 §19.7), and the affected tests use non-empty tokens. Thank you for the review — please let me know if anything else needs adjustment.