Qt Network changes in Qt 6

This issue collects the various changes planned for Qt 6.0. The high-level goals for these changes are:

• less overhead, esp in SSL/TLS/SChannel implementations, such as (QTBUG-80338)
  • avoid copying of data
  • efficient handshakes
  • avoid nesting of socket objects by making crypto functionality separate from socket I/O
• better testability (Is this Qt 6, or later, or earlier?)
  • allow implementation of mocks and stubs for testing protocols
• clean up and remove deprecated and obsolete stuff
  • bearer management (QTBUG-76502)
  • optimistic caching (remove connections from cache on error)
  • remove enums and code for deprecated versions of TLS (QTBUG-76501)
  • unify QtWebSocket with other networking classes (out of scope)
  • FTP-Support in NAM / QFtp (QTBUG-80339)
  • review our backends - OpenSSL code is very old, make sure we are not using deprecated APIs, the same is true about SecureTransport (QTBUG-80338)
  • make sure our use of TLS libraries is correct and secure (QTBUG-80338)
  • improve and modernise resources management (QTBUG-80368)
• Add API for certificate management (QTBUG-76499)
• Consider making QNAM Backends dynamic (QTBUG-80340)
• Get rid of ambiguous error reporting signals in network classes (QTBUG-80369)

Related work, but not necessarily targeting Qt 6.0, includes

• researching upcoming network functionality in the C++ standard and other frameworks
• feature-parity across platforms (esp regarding OCSP, TLS 1.3 , PSK)
• QSslConfiguration and QSslSocket::add[Default]CaCertificates

• • The related getters on QSslSocket are deprecated, slated for removal
  • There is no direct API replacement on QSslConfiguration for adding (other than list = getCaCerts, list.append(), setCaCerts(list))

Naming of classes should be considered - if we make significant changes to the architecture, then moving the existing QSsl* classes out of QtNetwork and instead providing TLS classes and specialized classes (such as QX509Certificate instead of QSslCertificate) would avoid naming conflicts.

This work depends on changes in QtCore, esp any changes to QIODevice, and a possible platform-abstraction for OS services.