use_ssl: True broken on Python 3.10 and later

[pquentin]

@lhuet reported us an issue where the following command:

esrally race --track http_logs --pipeline=benchmark-only --target-hosts="<snip>.elastic-cloud.com:9243" \
   --client-options="timeout:60,use_ssl:true,verify_certs:false,basic_auth_user:'elastic',basic_auth_password:'mypassword'"

failed like this:

elasticsearch.exceptions.SSLError: ConnectionError(Cannot create a client socket with a PROTOCOL_TLS_SERVER context
(_ssl.c:801)) caused by: SSLError(Cannot create a client socket with a PROTOCOL_TLS_SERVER context (_ssl.c:801))

The issue is in esrally/client:py:

rally/esrally/client.py

Lines 138 to 142 in 609a043

	# ssl.Purpose.CLIENT_AUTH allows presenting client certs and can only be enabled during instantiation
	# but can be disabled via the verify_mode property later on.
	self.ssl_context = ssl.create_default_context(
	ssl.Purpose.CLIENT_AUTH, cafile=self.client_options.pop("ca_certs", certifi.where())
	)

Even though literally everyone thinks the comment is true at first, it's wrong. For a client socket, ssl.Purpose.SERVER_AUTH should be used, with or without client certs. Everyone agrees that ssl.Purpose is super confusing, see python/cpython#73996. Anyway, in 3.10 making this mistake isn't possible anymore: python/cpython#26646.

However, just using SERVER_AUTH is not enough, because it activates more checks. When fixing this we need to make sure that:

• SSLContext attributes are changed in the correct order (eg.disabling verification is only possibly if hostname checking is disabled)
• client certs still work
• SSL connections to IP address still work (we will probably need Fix HTTPS connection when host is an IP address elastic-transport-python#81)
• bonus points for catching all of this in tests (https://gist.github.com/dliappis/97d013ab6e0e3250fdd6cbfba8e58a5c is great - can it be part of IT tests? Or maybe we can use trustme + a simple http server)