WL#12990: Group Replication: TLS 1.3 support

EXECUTIVE SUMMARY
==============================

WL#12361: "Support TLS 1.3 in the server and libmysql" implemented support of
TLS 1.3 on the server which did not consider Group Replication, in particular GCS.
The outcome is that when the server is configured to only use TLS 1.3, then Group
Replication will not start throwing a error saying that it does not support TLS 
1.3.

USER/DEV STORIES
==============================

As a MySQL DBA, i want to be able secure communication using TLS 1.3 among all 
group members in order to use the latest and greatest security features available. 

SCOPE 
==============================

This worklog will implement TLS 1.3 support on GCS/XCom.

LIMITS
==============================

N/A

FR-1: It must be possible to use TLS 1.3 in XCom links
FR-2: It must be possible to join a node that does not have this feature 
implemented to a group that has this feature implemented
FR-3: It must be possible to join a node that has this feature implemented to a 
group that does not have this feature implemented.

All other requirements must respect FRs and NFRs from WL#12361.

SUMMARY OF THE APPROACH
=====================================

With the advent of TLS 1.3, which is backwards-incompatible with other
protocol versions, there was the need to add extra variables and fields
to MySQL in order to configure it. 

Since GCS/XCom maintain their own communication layer, one needs to pass
those new configuration parameters to the GCS/XCom layer.

The bulk of the work is to use the new parameter tls_ciphersuites
inside XCom, adding a new configurable parameter on GCS interface.

SECURITY CONTEXT
======================================

This WL will augment GCS/XCom to use TLS 1.3, hence reducing possible
attacks.

UPGRADE/DOWNGRADE and CROSS-VERSION REPLICATION
======================================

This WL is affected and it must be tested for Upgrade/Downgrade.

In generic terms, OpenSSL is able to negotiate a connection to make sure
that it uses the most secure protocol configured by the user, if everyone
configures all available protocols. Trouble arises when a user
configures a specific protocol, or ciphers that are not supported by
the available protocols. 

UPGRADE
======================================

If a node wants to join a group that only speaks, at maximum, TLS 1.2,
which is the previous supported version, it must enter the group making
sure that it has protocols under 1.3 supported and configured. OpenSSL 
will take care of the negotiation and make sure that everyone speaks the
best protocol available. When this is done, the whole group will
communicate using the best protocol available.

This means that, if a DBA configures the new node to *ONLY* use TLS 1.3,
it won't be able to enter an old group.

In order to make sure that everyone is using TLS 1.3, if configured,
one needs to make a group rolling restart. Then, all members will now
start using TLS 1.3

DOWNGRADE
=====================================

If an old node wants to join a group that speaks at maximum, TLS 1.3,
one needs to make sure that the group is configured with previous 
versions of the TLS protocol. As in the Upgrade section, if the group
only speaks TLS 1.3, old nodes won't be able to join it.

If the group is configured in a traditional way, meaning that it supports
TLS versions under 1.3 starting at TLS 1.0, an old node can join without
any issue. If the group is configured to only speak TLS 1.3, one needs to
configure any necessary previous version of the protocol compatible 
with the node that we want to add and execute a rolling restart of the
group.

USER INTERFACE
===================================

Implementing TLS v1.3 brought a new configuration item to MySQL:
https://dev.mysql.com/doc/refman/8.0/en/server-system-
variables.html#sysvar_tls_ciphersuites.

This can now be configured and it has meaning in Group Replication.

OBSERVABILITY
===================================

N/A

DEPLOYMENT and INSTALLATION
===================================

N/A

PROTOCOL
===================================

We will now support TLS 1.3 with all the implications that are already
described in the Upgrade/Downgrade section.

FAILURE MODEL SPECIFICATION
===================================

N/A

BLOCK DIAGRAM
=====================================

N/A

INTERFACE SPECIFICATION
=====================================

A new parameter must be passed to GCS in order to configure the new 
TLS Cipheruites for TLS 1.3. As such, GR must now do the following:

gcs_module_parameters.add_parameter("tls_ciphersuites", <>)

<> must be extracted from the system variable 
"tls_ciphersuites"

DESIGN IMPLEMENTATION STEPS
=====================================

The goal of this WL is to add full support for TLS 1.3. This means that:
- We must accept TLS 1.3 as protocol;
- Configure the new tls_ciphersuites parameter for establishing a connection.

The implementation is heavily based in WL#12361.

Accepting TLS 1.3 is out-of-the-box, because it is just another value in
tls_version sysvar. It is transparent to us.

In order to  configure the new tls_ciphersuites parameter for 
establishing a connection, one needs to pass it to XCom, via GCS.
It will get its value from the new sysvar "tls_ciphersuites".

We need to modify:
- gcs_xcom_interface.cc in order to receive the new parameter in 
  "configure_xcom"
- gcs_xcom_proxy.cc
-- xcom_set_ssl_parameters() to receive the new parameter
-- xcom_init_ssl() to call XCom's xcom_init_ssl with the new parameters
- xcom_ssl_transport.* to accept, configure and support TLS 1.3 and the
  new parameter

Note that, in order to support our smoke tests, one must change the
input parameters of xcom_set_ssl_parameters to a struct, because they
exceed the maximum allowed number of parameters of GMock.