Do not collapse ssl_crtd requests across reconfigurations

[eduard-bagdasaryan]

Squid collapses new ssl_crtd requests on a pending request with an identical helper query. This collapsing "works" across Squid reconfigurations even though the old helper responsible for the first request is replaced with a new one during reconfiguration; that old helper must complete servicing pending requests.

However, since the helper program itself could have been changed (just prior to reconfiguration), it is conceptually wrong for post-reconfiguration requests to reuse the old helper program response: Squid must conservatively assume that the response may have changed because the helper protocol does not allow Squid to validate the freshness of the helper response (to a collapsed request). Such blind reuse also creates runtime problems if a buggy helper never responds to a request X, stalling all the new requests getting collapsed on X (until a Squid restart).

The added squid.conf "tagging" or "versioning" scheme may be useful for Squid DNS and HTTP collapsing features that lack freshness checks and, hence, should not use potentially stale pending transactions as collapsing targets for new transaction after a reconfiguration.

Also pool GeneratorRequests map entries.