bugfix: reject settrustedstore on already-handshaked cosocket

[perfgao]

Summary

tcpsock:settrustedstore() called on a cosocket whose TLS handshake has already completed silently became a no-op, while appearing to succeed. The new X509_STORE was stashed into u->ssl_trusted_store, but a subsequent tcpsock:sslhandshake() short-circuits via the c->ssl->handshaked early return in ngx_http_lua_ffi_socket_tcp_sslhandshake and never reaches the SSL_set1_verify_cert_store() block at src/ngx_http_lua_socket_tcp.c:1942. As a result the connection continued to verify the peer against the trust anchor configured before the first handshake — users believed they had swapped trust anchors, but they had not.

Fix

Reject the call at the FFI entry when the underlying TLS connection is already established, so callers get a clear error instead of a silently ineffective swap.

if (u->peer.connection->ssl
    && u->peer.connection->ssl->handshaked)
{
    *errmsg = "ssl handshake already done; trusted store cannot be "
              "changed on an established TLS connection";
    return NGX_ERROR;
}

• Scope is intentionally narrow: only ngx_http_lua_ffi_socket_tcp_settrustedstore is touched.
• The handshake state machine and session-reuse semantics are unchanged.
• Returning NGX_ERROR here is the existing FFI argument-validation path — it does not close the connection; the Lua wrapper just surfaces nil, err to the caller.

Reproduce (before patch)

local sock = ngx.socket.tcp()
sock:connect(host, 443)
sock:settrustedstore(store_a)
sock:sslhandshake(false, host, true)   -- verified against store_a

sock:settrustedstore(store_b)          -- silently stored
sock:sslhandshake(false, host, true)   -- returns OK, still verified against store_a

After the patch the second settrustedstore returns nil, "ssl handshake already done; trusted store cannot be changed on an established TLS connection".

Notes

The same early-return path in ffi_socket_tcp_sslhandshake also ignores re-supplied verify, SNI, OCSP and client cert/key when the cosocket is already handshaked. Those are out of scope for this PR — happy to do a follow-up if maintainers want symmetric protection at the same layer.