PR#3244
(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed)

Always add a dynamically loaded ENGINE to list. Otherwise it can cause
problems when multiply loaded, especially if it adds new public key methods.
For all current engines we only want a single implementation anyway.

Partial fix for PR#3183.

PR#3178

If available rdrand is used as an additional entropy source for the
PRNG and for additional input in FIPS mode.

change documentation and comments to indicate that we prefer the
standard "DHE" naming scheme everywhere over the older "EDH"

Replace the full ciphersuites with "EDH-" in their labels with "DHE-"
so that all DHE ciphersuites are referred to in the same way.

Leave backward-compatible aliases for the ciphersuites in question so
that configurations which specify these explicitly will continue
working.

This change normalizes the SSL_CK_DHE_ #defines to use the common term
"DHE", while permitting older code that uses the more uncommon "EDH"
constants to compile properly.

DHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEDH should probably be deprecated at some
point, though.

other parts of packet tracing emit the standard "DHE" label instead of
"edh".  This change brings the output of ssl_print_client_keyex() and
ssl_print_server_keyex() into accordance with the standard term.

The standard terminology in https://tools.ietf.org/html/rfc5426 is
"DHE".  "openssl ciphers" outputs "DHE" (for the most part).  But
users of the library currently cannot specify "DHE", they must
currently specify "EDH".

This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.

ECDHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEECDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEECDH should probably be deprecated at some
point, though.

other parts of packet tracing emit the standard "ECDHE" label instead
of "EECDH".  This change brings the output of ssl_print_client_keyex()
and ssl_print_server_keyex() into accordance with the standard term.

The standard terminology in https://tools.ietf.org/html/rfc4492 is
ECDHE.  "openssl ciphers" outputs ECDHE.  But users of the library
currently cannot specify ECDHE, they must specify EECDH.

This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.

(cherry picked from commit 6b42ed4e7104898f4b5b69337589719913b36404)

(and shave off cycle even from integer-only code)

(and update performance data, and fix typo)

Fix a limitation in SSL_CTX_use_certificate_chain_file(): use algorithm
specific chains instead of the shared chain.

Update docs.

but keep it disabled, too little gain... Add some Atom-specific
optimization.

When sending an invalid version number alert don't change the
version number to the client version if a session is already
established.

Thanks to Marek Majkowski for additional analysis of this issue.

PR#3191