Server-side keyring certificates: kernel never populates ta_my_cert / ta_my_privkey

tlshd links the .nfsd keyring into its session keyring at startup, and the handshake upcall protocol defines attributes for passing a certificate and private key serial number to the server-side handshake. However, the kernel's svc_tcp_handshake() never populates ta_my_cert and ta_my_privkey, so an NFS server has no path to present a certificate stored in the .nfsd keyring; tlshd always falls back to the certificate configured in /etc/tlshd.conf.

Making this work requires kernel changes (an administrative interface for nfsd to select keyring-resident authentication material, and svc_tcp_handshake() filling in the handshake args) in addition to whatever tlshd-side handling is missing. Once it does work, server-side keyring certificates have the same dual/PQ certificate gap tracked in #151.

Observed by Scott Mayhew while triaging the client-side keyring regression:
https://lore.kernel.org/all/afUKzeUYPhb97DX4@aion/

Start with the kernel's svc_tcp_handshake() and the handshake upcall attributes ta_my_cert and ta_my_privkey, then trace how tlshd links the .nfsd keyring and reads /etc/tlshd.conf. The work is complete when an NFS server can select keyring-resident certificate material and pass its serial numbers through the handshake instead of always using the configured certificate.