Query SSL_pending lazily in ReferenceCountedOpenSslEngine.unwrap - #18376

Motivation:

ReferenceCountedOpenSslEngine.unwrap(...) calls SSL.sslPending(...) through JNI at the start of every call once the handshake is finished. The value is only read in two places:

• when the sources are empty (len == 0), to decide between BUFFER_UNDERFLOW and draining plaintext that is still inside the engine;
• when the loop meets an empty source buffer, for the same decision.

For the common case of one non-empty source the value is never used. In a 300 s production CPU profile of a server handling many small TLS records (Netty 4.2.20, netty-tcnative-boringssl-static 2.0.85) SSL.sslPending accounts for about 1.7% of all samples.

Modification:

• Do not query SSL_pending up front. Fetch it where it is read: in the len == 0 check, and on the first empty source buffer met in the loop. A SSL_PENDING_UNKNOWN sentinel marks "not queried yet"; SSL_pending never returns a negative value. The refresh after a destination buffer is filled is unchanged.
• Add OpenSslEngineTest.testUnwrapEmptySourceDrainsPendingPlaintext: it unwraps one full record into a too small destination, then drains the plaintext left inside the engine through an empty source and through an empty source that is one of multiple sources, and checks BUFFER_UNDERFLOW once nothing is left. Neither path had a dedicated test.

Result:

One JNI call less per unwrap in the common case, with the same results.

The value used for an empty source buffer in the loop can now be newer than the one taken at the start of the call. That does not change the outcome: a newer zero skips the buffer directly, where the older non-zero value would have led to a read that returns nothing and then skipped it.