gh-148594: Clear stale OpenSSL errors before TLS. I/O.

[mahhie418]

This PR. fixes #148594 and fixes #81891 (duplicate reports of the same bug), following the discussion in #148597.

Stale entries in the thread-local OpenSSL error queue can cause SSL_get_error() to misclassify retryable conditions, leading to spurious exceptions.

Clear the queue immediately before each SSL_read_ex(), SSL_write_ex(), SSL_do_handshake(), SSL_shutdown() and SSL_sendfile() invocation, including retries. Error classification remains immediately after each operation.

Clearing errors only where CPython raises them would not cover entries left by other OpenSSL users on the same thread. Clearing at the I/O. call sites ensures that the precondition is met regardless of where the stale errors originated.

Add regression tests for read(), write() and unwrap(), based on the reproducer provided by @devdanzin in #148594. They reuse the existing test infrastructure and certificate fixtures without requiring ctypes, gevent, external network access or certificate generation. All three fail before the fix and pass afterwards.

The handshake and sendfile changes enforce the same documented precondition. A stale-queue failure has not been reproduced in the handshake path, and Kernel TLS sendfile was not tested on macOS. SSL_pending() is unchanged because it reports buffered byte counts rather than the result of a TLS. I/O. operation.

Validation on macOS arm64 with a CPython 3.16 debug build and OpenSSL 3.5.9:

• ./python.exe -m test test_ssl
• ./python.exe -m test -R 3:3 test_ssl
• ./python.exe -m test -j0
• make patchcheck

All checks passed. No leaks were reported after warm-up. The default suite completed with platform and resource skips.

• Issue: ssl.SSLSocket.read() / write() missing ERR_clear_error() before SSL_read_ex() / SSL_write_ex() causes spurious errors with cooperative threading #148594

[python-cla-bot]

All commit authors signed the Contributor License Agreement.