Sync changes from WinRb/WinRM upstream

[tas50]

Summary

Brings across the changes made in WinRb/WinRM since the two projects diverged at v2.3.9 (2024-08-02), so the forks stay reconcilable.

Rebased onto current main (9710771). Upstream has 16 commits since that point. Each was reviewed individually rather than merged wholesale — a straight merge would have dragged in ~135 files of rename and quote-style churn, since this fork moved lib/winrm/ to lib/chef-winrm/ and reformatted to cookstyle --chefstyle. The five commits here are hand-ported and follow this repo's conventions.

What's included

Replace the logging gem with the standard library Logger (upstream WinRb#358, WinRb#360)

Removes a runtime dependency. The gem was used in exactly three places: parsing WINRM_LOG, building Connection#logger, and building a second unrelated logger inside HttpTransport. WinRM.default_log_level now handles WINRM_LOG, warning and falling back to :warn on an unrecognized value.

Connection#logger returns WinRM::CompatLogger, a stdlib Logger subclass that still accepts add_appenders — the one logging-specific call consumers actually used. It warns once per instance and does nothing, so existing code keeps running rather than raising NoMethodError on upgrade.

This also fixes a latent bug: the transport built its own logger, so a logger assigned to Connection#logger never reached it. The transport now receives the connection's logger.

Close orphaned shells via at_exit when finalizers can't spawn threads (upstream WinRb#354)

Ruby 3.1 forbids allocating a thread inside a finalizer, which this repo worked around by making the finalizer a no-op. That stopped the ThreadError but leaked the remote shell: it survived on the WinRM server until its idle timeout expired, occupying one of the server's limited shell slots meanwhile.

The finalizer now attempts the thread as before and, when the interpreter refuses with can't alloc thread, defers the close to at_exit. Unrecognized ThreadErrors still propagate, and a failure inside the deferred close warns rather than raising, since an exception from at_exit would obscure the program's real exit status. Adds coverage for all four paths; the no-op version had none.

Exclude the broken rubyntlm 0.6.7

Not part of the upstream sync, but CI surfaced it here and it blocks everything.

rubyntlm 0.6.7, released 2026-09-14, extracted the session key derivation methods into Net::NTLM::Client::SessionCrypto but left CLIENT_TO_SERVER_SEALING and the other three key constants behind in Net::NTLM::Client::Session. Ruby resolves a constant referenced in a method body through the lexical scope where the method was written and that scope's ancestors, not through the ancestors of the class that later includes the module, so Session is never searched. All four derivations raise NameError.

The negotiate transport reaches them via seal_message/unseal_message, so with 0.6.7 installed every NTLM and Negotiate connection fails. Negotiate is the default transport, so this breaks essentially all usage on a fresh install. 0.6.5 and 0.6.6 are unaffected; the constraint excludes only 0.6.7 so a fixed 0.6.8 is picked up automatically.

Nothing in the unit suite touched that path, so it only failed in the integration suite, which needs a live Windows host. Added a contract spec covering all four derivations — it fails in seconds against 0.6.7 and passes against 0.6.5 and 0.6.6.

Fix the dead AppVeyor link in the certificate auth instructions (upstream WinRb#364) — the AppVeyor removal itself landed separately in #33 while this PR was open, so rebasing reduced this commit to its residual: the README pointed at WinrmAppveyor.psm1 on the WinRb/WinRM master branch as an openssl example, and that link is doubly dead now that the branch is main and the file is gone from both repos. It names openssl directly instead.

Rename changelog.md to CHANGELOG.md — GitHub and RubyGems don't surface the lowercase spelling.

Run the unit workflow on pushes to main — its push trigger still named master, a branch this repo doesn't have, so unit tests ran on PRs but never on merge. Noticed while reviewing the upstream CI commits.

Deliberately not included

• PSRP object_id rename (upstream Rename object_id to message_id WinRb/WinRM#352) — both forks renamed it to avoid shadowing Object#object_id, but upstream chose message_id while this fork chose psrp_object_id/custom_object_id. Keeping this fork's names; converging would break anyone pinned to 2.4/2.5.
• Kerberos realm/service validation (upstream Validate realm/service options for kerberos transport WinRb/WinRM#363) and REXML 3.4.4 nodeset fix (upstream Fix REXML 3.4.4 nodeset warnings in fault handling WinRb/WinRM#362) — already implemented here independently in 2ee633b and d0cbbb8. Verified equivalent line by line.
• 2.4.0 version bumps, rubocop config, build-chain and CI modernization — this fork is at 2.5.0 with its own cookstyle-based CI.

Fork-specific choices left untouched: chef-gyoku, Ruby >= 3.1, cookstyle over rubocop, and the pinned rexml >= 3.4.2 for CVE fixes.

Testing

• bundle exec rake spec — 256 examples, 0 failures, 2 pending (was 238 on main; +18 new tests covering the finalizer paths, CompatLogger, default_log_level, and the rubyntlm key derivations)
• bundle exec cookstyle --chefstyle -c .rubocop.yml — no offenses on any changed file (the two Style/ModuleMemberExistenceCheck offenses it reports are pre-existing on main, in files this PR does not touch)
• Verified at runtime that the logging gem is no longer loaded, the transport shares the connection's logger, and both the valid and invalid WINRM_LOG paths behave correctly