QNetworkReply has wrong sslConfiguration

I am have a code that connects to QNetworkReply::encrypted and examinesQNetworkReply::sslConfiguration().peerCertificateChain(). Sporadically, the chain ends up empty. The documentation for 'encrypted' say that checking certificate chain and calling abort is actually intended usage, so this seems like a bug to me. Sadly, the bug is not easy to reproduce reliably, but I could narrow it down to an internal inconsistently inside HTTP implementation.

Namely, when QHttpNetworkConnectionChannel::_q_encrypted emits 'encrypted' on QHttpNetworkReply, the QHttpNetworkReply is often associated not with the channel we're in, but with the first channel of the parent QHttpNetworkConnectionChannel. The attached patch (detection.diff) adds an assert that connectionChannel is right, and with that, the attached trivial HTTP request program triggers the assert immediately.

I will submit a possible fix shortly.

I would guess that in my original case, I send several requests and normally, the request send through first channel also completes first, sets peer certificate chain inside, and then the fact that QHttpNetworkReply on other channels are mistakenly associated with first channel does not matter - since sslConfiguration is already set. However, when replies are send and cancelled quickly, sometimes we get response on channel that is not first, while the first channel has no sslConfiguration.