Add the extension parser in the s_client, ocsp and x509 apps.

The flag SSL_OP_MSIE_SSLV2_RSA_PADDING hasn't done anything since OpenSSL
0.9.7h but deleting it will break source compatibility with any software
that references it. Restore it but #define to zero.
(cherry picked from commit b17d6b8d1d49fa4732deff17cfd1833616af0d9c)

Add the RFC6962 OIDs to the objects table.

(cherry picked from commit a2317c3ffde3f1f73bd7fa3f08e420fb09043905)

The contract for custom extension callbacks has changed - all custom extension callbacks are triggered

Whitespace fixes

If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake.

Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.

If an application calls the macro SSL_CTX_get_extra_chain_certs
return either the old "shared" extra certificates or those associated
with the current certificate.

This means applications which call SSL_CTX_use_certificate_chain_file
and retrieve the additional chain using SSL_CTX_get_extra_chain_certs
will still work. An application which only wants to check the shared
extra certificates can call the new macro
SSL_CTX_get_extra_chain_certs_only

This allows to process multiple fragmets of maximum fragment size,
as opposite to chopping maximum-sized fragments to multiple smaller
ones. This approach relies on dynamic allocation of larger buffers,
which we trade for performance improvement, for several *times* in
some situations.

If application has more data than maximum fragment, hold to buffer
for whole write, as opposite to per-fragment strategy.

New ctrl sets current certificate based on certain criteria. Currently
two options: set the first valid certificate as current and set the
next valid certificate as current. Using these an application can
iterate over all certificates in an SSL_CTX or SSL structure.

PR#3244
(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed)

Partial fix for PR#3183.

PR#3178

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)

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

Update docs.

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