[fix] SSL session resumption failure due to BC classloader mismatch (…

[Thiagott]

Fixes #369.

---

What breaks and why

During bundle install on a long-lived JVM, any Java gem with a post-install hook
(e.g. fast-rsa-engine, digest-crc, psych) can load BouncyCastle JARs via Maven
under a new classloader. Once that happens there are two copies of BC in the same JVM,
and two bugs combine to make every subsequent HTTPS connection fatal.

Issue 1 — BCSSLSupport

ProvSSLEngine.setBCSessionToResume throws IllegalArgumentException because the stored
BCExtendedSSLSession came from a different classloader than the current engine. That
exception was uncaught and propagated as an SSLError.

Issue 2 — SSLSocket

When setBCSessionToResume returned false, we called engine.setEnableSessionCreation(false).
If the stored session then couldn't be resumed for any reason, BC-JSSE threw instead of falling
back to a fresh handshake — which is the error users see:

OpenSSL::SSL::SSLError: No new session is allowed and no existing session can be resumed

Neither bug alone explains the full failure — both need to be fixed together.

---

The fix

File	Change
BCSSLSupport.java	Catch IllegalArgumentException from setBCSessionToResume and return false so the caller falls back to a fresh handshake
SSLSocket.java	Remove setEnableSessionCreation(false) — it was intended to enforce session reuse but makes any resumption failure unrecoverable

---

Testing

Tested locally on macOS with JRuby 9.4.13.0 and a Gemfile that pulls in fast-rsa-engine,
digest-crc, ruby-maven-libs, and psych — all gems that trigger JAR classloading via
post-install hooks.

	Result
Without patch	Fails at the first HTTPS fetch after hooks run
With patch	Bundle complete! 101 gems now installed. ✓