_set_options and _clear_options take a box receiver but mutate the context

[SeanTAllen]

_set_options (ssl/net/ssl_context.pony:90) and _clear_options (ssl/net/ssl_context.pony:101) are declared fun — the default box receiver — but both reconfigure the OpenSSL context. _set_options calls SSL_CTX_set_options on OpenSSL and SSL_CTX_ctrl on LibreSSL; _clear_options calls SSL_CTX_clear_options or SSL_CTX_ctrl. Every other method that changes the context — set_cert, set_ciphers, set_verify_depth, set_min_proto_version, set_max_proto_version, alpn_set_resolver — is fun ref. These two are not.

box accepts a val receiver. The package is built on holding a context val: SSLContext is a class val, client and server are fun val (ssl/net/ssl_context.pony:118, :130), and SSL._create takes SSLContext val. A context held val is one the holder treats as frozen. _set_options and _clear_options let it be reconfigured anyway.

Nothing exercises this today. The only callers are allow_tls_v1, allow_tls_v1_1, and allow_tls_v1_2 (ssl/net/ssl_context.pony:435, :449, :463), all fun ref, so no val receiver reaches the mutators now. The capability is still wrong: a fun val or fun box method added later could call either one and reconfigure a frozen context, and it would compile.

Fix direction

Declare both fun ref. That matches every other mutating setter on the type and stops a val receiver from reaching them. The three existing callers are already fun ref, so the change compiles as-is.