This PR is a continuation of #25478, that was no longer updated by the author @hashbrowncipher.
I implemented all the requested changes.

However, the optimization changes behavior of an SSLSocket.recv. Therefore I introduced a parameter to enable this new behavior only when desired.

The change in behavior if we don't add an opt-in:

Right now callers can rely on fact that either SSLSocket.read returns bytes OR it reads a TLS close_notify message, producing an exception; it never does both. With this change, it becomes possible to read application data and also read a TLS close_notify message, which will be processed by OpenSSL. select/poll/epoll will all now indicate that the socket has no bytes available (which is true), but OpenSSL knows that no additional bytes will ever arrive on the socket. I validated my theory by patching the test_ftplib code to check for EOF after successful reads. With this change, the tests all passed.

That said, I don't imagine it's acceptable to change behavior like this. I think that to roll out this optimization would require calling code to opt in by passing a flag indicating "Please read eagerly from the socket; I know that I am responsible for explicitly checking for EOF before calling select() on the underlying OS socket."

It was requested in the review to also implement this for write(), however, that is not needed as OpenSSL's SSL_write_ex already writes the whole buffer at once. Only reading OpenSSL does in the 16k segments.

Original PR-text:

Continue looping until data is exhausted, and only then reacquire the GIL. This makes it possible to perform multi-threaded TLS downloads without saturating the GIL. On a test workload performing HTTPS download with 32 threads pinned to 16 cores, this produces a 4x speedup.

                          before     after
wall clock time (s)  :    29.637     7.116
user time (s)        :     8.793    12.584
system time (s)      :   105.118    30.010
voluntary switches   : 1,653,065   248,484
speed (MB/s)         :      4733     19712

https://bugs.python.org/issue37355

Closes #25478.
Closes #81536

https://bugs.python.org/issue37355