[2.5] Support one-way SSL

[yanchengnv]

Fixes # .

Description

So far, FL clients and the FL Server must connect via mTLS (i.e. two-way SSL). Customers have been asking for the support of one-way SSL between FL clients and the FL Server. This PR adds this support to Flare 2.5.

When provisioning a project, the Project Admin can now specify "connection_security" property for the whole project, as well as for individual sites (server and clients). Valid values of this property are: clear, insecure, tls, and mtls:

• clear or insecure: the connection is clear - no SSL
• tls or TLS: one-way SSL
• mtls or mTLS: mutual TLS, a.k.a. two-way SSL

For one-way SSL, the Project Admin can further specify "custom_ca_cert", which must be a valid cert file (extension must be .pem). If specified, then the client will use it to connect to the server, instead of using the provisioned CA cert. Custom CA Cert is necessary when the customer wants to connect the client to a middleman like ALB, where the cert belongs to the ALB.

The "connection_security" can also be explicitly set for a site. If set, then the site's connection security takes precedence over the project's connection_security. Hence in the same project, some sites could be running in clear, some in TLS, and some in mTLS. This is necessary to allow customers to deploy FL server and clients according to their IT requirements (e.g. use proxies, ALBs, etc.). This is one step towards the support of BYOConn (bring your own connectivity).

Once provisioned, the fed_server.json and fed_client.json will be generated with the value of "connection_security". If custom CA cert file is provided, it will be copied into the startup kit of each site as "customRootCA.pem".

Note that the "secure_train" arg no longer always determines connection security! The connection security is determined by the value of "connection_security" property specified during provision. If this property is not explicitly specified, then the "secure_train" arg is used to determine connection security, and mTLS is used when secure_train is true.

Note that the Provisioner will continue to generate self-signed certs and keys for all participants, regardless the value of "connection_security". In the future, even if these credentials are not used for connectivity, they will be used for explicit identity verification.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Quick tests passed locally by running ./runtest.sh.
• In-line docstrings updated.
• Documentation updated.