ssl: parse SNI in received client hello records
added SNI decode test to SSL handshake suite
Merge branch 'dnet/parse_sni' into maint

* dnet/parse_sni:
  added SNI decode test to SSL handshake suite
  ssl: parse SNI in received client hello records

OTP-12048
ssl: Correct handling of certificate_types in Certificate Requests

FROM TLS 1.2 RFC:
   The interaction of the certificate_types and
   supported_signature_algorithms fields is somewhat complicated.
   certificate_types has been present in TLS since SSLv3, but was
   somewhat underspecified.  Much of its functionality is superseded by
   supported_signature_algorithms.  The following rules apply:

   -  Any certificates provided by the client MUST be signed using a
      hash/signature algorithm pair found in
      supported_signature_algorithms.

   -  The end-entity certificate provided by the client MUST contain a
      key that is compatible with certificate_types.  If the key is a
      signature key, it MUST be usable with some hash/signature
      algorithm pair in supported_signature_algorithms.

   -  For historical reasons, the names of some client certificate types
      include the algorithm used to sign the certificate.  For example,
      in earlier versions of TLS, rsa_fixed_dh meant a certificate
      signed with RSA and containing a static DH key.  In TLS 1.2, this
      functionality has been obsoleted by the
      supported_signature_algorithms, and the certificate type no longer
      restricts the algorithm used to sign the certificate.  For
      example, if the server sends dss_fixed_dh certificate type and
      {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
      with a certificate containing a static DH key, signed with RSA-
      SHA1.
ssl: Test ECDSA and improve test suite maintainability

Use generated certs instead of hard coded
ssl: Make sure the correct ROOT-cert is used

When dealing with older certificates that does not indicate its signer
with a certificate extension, we must search the database for the issure.
Finding the issuer is not enough, we need to verify the signature
with the key in the found issuer cert.
ssl: Fix broken contract
ssl: Fix boolean expression
Fix misspellings of 'another'
ssl, public_key: Add new option partial_chain

Check that the certificate chain ends with a trusted ROOT CA e.i. a
self-signed certificate, but provide an option partial_chain to
enable the application to define an intermediat CA as trusted.

TLS RFC says:

"unknown_ca
      A valid certificate chain or partial chain was received, but the
      certificate was not accepted because the CA certificate could not
      be located or couldn't be matched with a known, trusted CA.  This
      message is always fatal."

and also states:

"certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case."

X509 RFC says:
   "The selection of a trust anchor is a matter of policy: it could be
   the top CA in a hierarchical PKI, the CA that issued the verifier's
   own certificate(s), or any other CA in a network PKI. The path
   validation procedure is the same regardless of the choice of trust
   anchor.  In addition, different applications may rely on different
   trust anchors, or may accept paths that begin with any of a set of
   trust anchors."
ssl: Prepare for release - soft upgrade
ssl: One more workaround as tcp has no delivery gurantee on application level
Update release notes