4.x: Introduce integration test for TLS session tickets

[Bouncheck]

Adds isolated SessionTicketsIT which checks if session tickets mechanism behaves as expected. It does that by watching Java's SSL debug logs and ensuring that specific substrings appear in them.

Since the server supports tickets with TLSv1.3, only that version is tested. In that version the session resumption without server-side state is done through pre-shared keys. The details are described in rfc8446 (see section 2.2).

[Bouncheck]

Tested with Java 8, 11 and 17.
Fixes #444

[dkropachev]

Way to test counters is prone to failure, if connection is re-estalished during the test (I have seen it happening), counters will drift and you going to get false-positive.

To test that TLS tickets work properly you need to establish connection, then break it and then check if ticket was reused, don't see it is happening here.

[Bouncheck]

Way to test counters is prone to failure, if connection is re-estalished during the test (I have seen it happening), counters will drift and you going to get false-positive.

I don't think the false positive (test passing when it should not) is possible here, but false negative is.
Are you opposed to all counter/logs based approaches? I can fix the drift by counting the number of seen handshakes (for example by counting ClientHellos) and making other checks depend on that number rather than hardcoded number.

To test that TLS tickets work properly you need to establish connection, then break it and then check if ticket was reused, don't see it is happening here.

There are 5 resumptions and 6 handshakes happening in this test. I can make the checks more explicit by tracking the ticket data from the logs and match it against what is reported to be received through NewSessionTicket messages.

[dkropachev]

Way to test counters is prone to failure, if connection is re-estalished during the test (I have seen it happening), counters will drift and you going to get false-positive.

I don't think the false positive (test passing when it should not) is possible here, but false negative is.

https://en.wikipedia.org/wiki/False_positives_and_false_negatives :

A false positive is an error in [binary classification](https://en.wikipedia.org/wiki/Binary_classification) in which a test result incorrectly indicates the presence of a condition (such as a disease when the disease is not present), while a false negative is the opposite error, where the test result incorrectly indicates the absence of a condition when it is actually present

Are you opposed to all counter/logs based approaches?

I’m totally fine with it, unless there’s a better way—which there isn’t.

I can fix the drift by counting the number of seen handshakes (for example by counting ClientHellos) and making other checks depend on that number rather than hardcoded number.
There are 5 resumptions and 6 handshakes happening in this test. I can make the checks more explicit by tracking the ticket data from the logs and match it against what is reported to be received through NewSessionTicket messages.

Given the fact that ChannelPool is initialized from one DriverChannel and later create per-shard DriverChannel's, it would be enough to test if Resuming session more than zero.