Thread safety

[djberg96]

Improve thread safety of ruby-gpgme. Hopefully addresses #115.

The ruby-gpgme gem has no thread safety mechanisms, which can cause "Bad file descriptor" errors when multiple threads perform GPG operations concurrently (e.g. in Rails/Sidekiq environments). The root causes include unsafe GC behavior with the C extension, lack of synchronization, and fragile fd handling in the passphrase callback.

Changes:

Removed RUBY_TYPED_FREE_IMMEDIATELY from all four typed data structs (Data, Ctx, Key, TrustItem). This flag allowed Ruby's GC to free the underlying C structs outside the GVL, which is unsafe when another thread may still be using them. Setting flags to 0 defers freeing to a safe point.

Added RB_GC_GUARD calls after blocking GPGME operations in 7 functions: gpgme_op_decrypt, gpgme_op_decrypt_verify, gpgme_op_sign, gpgme_op_encrypt, gpgme_op_encrypt_sign, gpgme_op_verify, and gpgme_op_keylist_next. This prevents the GC from collecting Ruby-wrapped objects (contexts, data buffers) while the C library is still using their underlying pointers.

At the ruby layer:

Added opt-out thread-safe mode via GPGME.thread_safe = true. When enabled, all block-form Ctx.new calls are serialized through a global Monitor (reentrant mutex). A Monitor is used rather than a Mutex because GPGME operations are reentrant — e.g. Crypto#sign → Ctx.new → Key.find → Ctx.new.

Improved Ctx.pass_function fd handling: uses explicit io.write instead of io.puts, sets autoclose = false to prevent Ruby from closing the fd that belongs to GPGME/gpg-agent, and wraps the write in error handling.

Usage

Thread-safe mode is on by default but can be altered GPGME.thread_safe = false if it's proving problematic for some reason.

[ueno]

Looks very reasonable, thank you!