SSL: error message default in object caching API.

LGTM.

Actually, it doesn't belong to this series and should be fixed separately, preferably prior to the next release.
Currently this is the reason for potential segfaults, see bad malloc reports.
Moved to #333.

I wonder if it is possible to restrict the effect to the keys that actually require passphrases. Is it even worth trying?

That's a good point.
I rewrote the patch to actually restrict only encrypted keys, based on callback invocation.
In the previous approach, it was possible to disable caching at all e.g. with ssl_password_file at the top level.

Do we know if the configurations that prompted the SSL cache work use ssl_password_file? Would that regress the configuration load time for them?

I'm not aware of how encrypted keys are widely used.
Disabling caching of encrypted keys still makes a noticeable speedup in my basic tests, because certificates itself are cached.

We can think about it later, if such requested arise.

I'm not sure if it's worth introducing both valid and inactivity with a proactive expiration logic.

I'd rather compare this to shared SSL sessions that have a similar expiration logic.
Here it is used to mitigate the problem of keeping cached items at the maximum configured size once fully populated.

Though, I don't see a strong effect from using it here, and it somewhat duplicates the "valid=" time, so it may have sense to rethink this parameter.

Changes:

• logic to prevent caching encrypted keys is rewritten
• cache nodes are now created after SSL object, because this is not needed for non-cacheable SSL objects (read: encrypted keys)
• the first two patches are swapped for more clear diff

Changes:

• partially reverted 7a26242 to allow caching encrypted keys with passphrase prompt, and related code simplifications.
• made "inactive=" actually gradually expire old nodes

Most notably, this change reuses ngx_file_info() and improves its error handling; improves cache policy for runtime objects.
To be re-based/merged into appropriate existing commits.

First, a general note: I feel like the logic in the dynamic cache introduction is getting too complex for a single commit.
Would it make sense to split it in 2 parts: basic dynamic cache implementation with reload from disk every time cn->valid expires, and another commit with the file info checks?

I've read the latest changes, and I disagree with equating the ability to revalidate an already cached entry with the ability to cache.
My rationale here:

• The connection cache is already opt-in, with an expectation that the user is aware of the configuration. It's unlikely that someone accidentally enables runtime cache for engine: keys, but doesn't want that to happen. I'd say, the expectation is exactly the opposite.
• There's not a lot of risk in keeping an object cached for valid even if we are unable to confirm that it wasn't updated and extend the life time past that. An ability to tune valid= or disable the cache for current context and your ngx_ssl_cache_purge patch cover all the negative cases I could imagine.
• Disabling caching for one of the two related objects should increase the likeliness of getting X509_R_KEY_VALUES_MISMATCH. We already have to do that for encrypted keys, no reason to add more special cases :(

I wonder if you have any other potential uses for ngx_ssl_cache_purge. Otherwise, I'd like to suggest an alternative: passing a flag like NGX_SSL_CACHE_FORCE_UPDATE to ngx_ssl_cache_connection_fetch. This way we can avoid reallocation of the cache node.
If you think the function already has too many arguments, we can make it a mask on index. There`s no less than 30 unused bits, might as well use a few.

Merged fixup commits to use as a new baseline.

Rebase.

Addressed @bavshin-f5 comments.

Addressed @bavshin-f5 comments.

• backed out change in ngx_ssl_cache_lookup
• adjusted comments

password callback fixes:

• MSVC C4701 bogus warning
• initialization order restored