QNetworkReply abort() won't work if you've disconnected all signals from it

We've discovered something quite unfortunate about QNetworkReply in that if you disconnect all signals from it because, for example, you're done with it, then abort() doesn't work any more.

So for example you might create a network request like so, to download some big file:

QNetworkRequest request(QUrl("https://www.example.com/some_big_file"));
QNetworkReply *reply = qnam->get(request);
QObject::connect(reply, &QNetworkReply::finished, []() {
  std::cout << "We're finished!" << std::endl;
});

And then you might want to abort it later, but you also don't want the `finished` signal to fire, so you do the following:

reply->disconnect(nullptr, nullptr, nullptr);
reply->abort();
reply->deleteLater();

The problem is that internally, QNetworkReply seems to connect up some signals to actually handle the abort(). So disconnecting everything on that first line above caused the abort() to silently not actually work. The network connection still chugs along downloading.

Now the fix is clear - just don't disconnect all signals. And we can do that. However the reason I'm filing this report is that I would expect either:

1. To be allowed to disconnect everything. In my mind, the QNetworkReply object returned by the QNAM is owned by the caller (we are the ones who have to delete it) so I would expect to be able to do what I want with it.
2. If not 1, then at least document this clearly. I couldn't find anything in the docs to indicate that this pattern would not be allowed.