Enclosed is a patch to support SSL_CTX caching and reuse. It deserves some
explanation on both implementation and usage.

In spite of the friendly advice to use the curl_easy_duphandle I sticked to
the share object, as my application doesn't duplicate easy handles. A new
share lock option was added - CURL_LOCK_DATA_SSL_CTX and a new share option
CURLSHOPT_SSL_CTX_MAX was added to control the number of cached SSL_CTX
objects (the default is 3). SSL_CTX objects are cached instead of being
freed and when a new one is created, first the cached is searched. If the
cache contains an existing SSL_CTX that was created with the same req_method
(!) is found in the cache it is reused (otherwise a new one is created).
There is an underlying assumption that :

* data->set.cert
* data->set.ssl.cipher_list
* data->set.ssl.CAfile
* data->set.ssl.CApath

are fixed, i.e. if a SSL_CTX is reused, all the calls to openssl that use
these properties are skipped. This assumption looks reasonable (to me :) as
these properties are mostly fixed per application. If they are not caching
should be avoided! This behavior can be fixed if required.

When the connection is freed, the SSL_CTX is cached, and if the max size is
reached old entries are thrown off the cache. To implement this properly I
had to change the connectdata structure and keep a direct pointer to the
share object. This is slightly unfortunate, but since when closing the
connection we can't rely on the existence of the easy handle, there was no
way around that.

Lastly, the cache is cleared when the share object is deleted.

Usage:
    curl_share_setopt(share,CURLSHOPT_SHARE,CURL_LOCK_DATA_SSL_CTX);
    curl_share_setopt(share,CURLSHOPT_SSL_CTX_MAX,2);

I've been running using this configuration for a couple of days now without
any problems.

Cheers,
Shmul