Add the RFC6962 OIDs to the objects table.

If you use "-newkey rsa" it's supposed to read the default number of bits from the
config file.  However the value isn't used to generate the key, but it does
print it's generating such a key.  The set_keygen_ctx() doesn't call
EVP_PKEY_CTX_set_rsa_keygen_bits() and you end up with the default set in
pkey_rsa_init() (1024).  Afterwards the number of bits gets read from the config
file, but nothing is done with that anymore.

We now read the config first and use the value from the config file when no size
is given.

PR: 2592

apps/pkcs12.c accepts -password as an argument.  The document author
almost certainly meant to write "-password, -passin".

However, that is not correct, either.  Actually the code treats
-password as equivalent to -passin, EXCEPT when -export is also
specified, in which case -password as equivalent to -passout.

Improve CBC decrypt and CTR by ~13/16%, which adds up to ~25/33%
improvement over "pre-Silvermont" version. [Add performance table to
aesni-x86.pl].

When a chain is complete and ends in a trusted root checks are also
performed on the TA and the callback notified with ok==1. For
consistency do the same for chains where the TA is not self signed.

(cherry picked from commit a2317c3ffde3f1f73bd7fa3f08e420fb09043905)

(other processors unaffected).

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.

PR#3253

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.

Atom Silvermont. On other CPUs one can observe 1% loss on some
algorithms.

+5% on Atom Silvermont, up to +8% improvement of legacy code.
Harmonize sha1-586.pl and aesni-sha1-x86_86.p with sha1-x86_64.pl.

Remove reference to ERR_TXT_MALLOCED in the error library as that is
only used internally. Indicate that returned error data must not be
freed.
(cherry picked from commit f2d678e6e89b6508147086610e985d4e8416e867)

PR#3244
(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed)