docs: Add gRPC Post-Quantum Cryptography Guide

[lqiu96]

Summary

This pull request expands the Post-Quantum Cryptography (PQC) User Guide in docs/post_quantum_cryptography_guide.md to cover gRPC transport in addition to HTTP/JSON.

This PR is stacked on top of PR #13963 (pqc-user-guide).

Highlights

• General PQC Architecture: Updates the guide to introduce PQC concepts, the Store-Now, Decrypt-Later (SNDL) threat model, and hybrid key exchange across Google Cloud Java client libraries.
• Dedicated gRPC Transport Section (Section 3):
  • Details the default grpc-netty-shaded transport engine bundling BoringSSL (netty-tcnative-boringssl-static) with built-in PQC hybrid key exchange support (X25519MLKEM768) in gRPC-Java 1.83.0+.
  • Explains handshake negotiation with Google Cloud Front End (GFE) endpoints and graceful fallback to classical TLS.
  • Explains gRPC HTTP/2 long-lived multiplexed channels (ManagedChannel) and how TLS overhead occurs once upon connection establishment.
• Verification (Section 7):
  • Explains why standard JVM -Djavax.net.debug flags do not capture gRPC handshakes when using grpc-netty-shaded.
  • Documents Netty SSL debug logging (-Dio.grpc.netty.shaded.io.netty.handler.ssl=DEBUG) and ClientInterceptor response header verification.
• Custom Configurations (Section 8):
  • Documents custom Netty SSL context configuration via InstantiatingGrpcChannelProvider.Builder.setChannelConfigurator(...).

[gemini-code-assist]

Code Review

This pull request expands the Post-Quantum Cryptography (PQC) User Guide to cover both gRPC and HTTP/JSON transports, adding comprehensive sections on gRPC transport architecture, platform compatibility, verification methods, and custom configurations. The review feedback suggests correcting the Netty SSL logging instructions to configure the logging framework directly rather than using a JVM system property, and removing an unused import in the gRPC configuration code snippet.

[gemini-code-assist]

Netty's logging is routed through its InternalLoggerFactory, which delegates to the application's active logging framework (such as SLF4J/Logback, Log4j2, or java.util.logging). Passing -Dio.grpc.netty.shaded.io.netty.handler.ssl=TRACE as a JVM system property will not configure the log level. Instead, the log level for the shaded package io.grpc.netty.shaded.io.netty.handler.ssl must be set to TRACE (or FINEST for JUL) within the application's logging configuration file to ensure TLS handshake details are visible.

For example, in a logging.properties file (JUL):

io.grpc.netty.shaded.io.netty.handler.ssl.level=FINEST

Or in a Logback configuration (logback.xml):

<logger name="io.grpc.netty.shaded.io.netty.handler.ssl" level="TRACE"/>

Suggested change

	#### Method 1: Netty SSL Debug Logging
	You can enable debug logging for Netty's shaded SSL handler to observe TLS handshake details:
	```bash
	java -Dio.grpc.netty.shaded.io.netty.handler.ssl=DEBUG -jar my-application.jar
	```
	#### Method 1: Netty SSL Trace Logging
	You can enable trace logging for Netty's shaded SSL handler to observe TLS handshake details by configuring your logging framework (such as JUL, Logback, or Log4j2) to set the log level for the package "io.grpc.netty.shaded.io.netty.handler.ssl" to TRACE (or FINEST).

References

1. When providing logging examples, use the logging level that will actually show the desired logs, even if it's a more verbose level like FINEST, rather than a less verbose level like FINE, if the actual logs are at the more verbose level.

[gemini-code-assist]

The import java.io.File is not used in this code snippet and can be safely removed to keep the example clean.