it's a bit meh but we want to get aggressive percent encoding, qurlquery
doesn't give us that.

so what we had before was that one would feed QUQs into the API, then
the Connection would decode the QUQ to more comprehensively encode it
before constructing the final request QUrl that gets passed to KIO.
this had a number of entirely unwanted side effects the QUQ internally
partially recodes from user input and we'd have to select a decoding
choice when getting it out of QUQ. depending on the input that went
gloriously wrong

e.g. password with the verbatim part %FF would decode to unicode

similarly we can't simply use a more limited decoding set because it
couldn't possibly small enough

e.g. a password with the verbatim part %3C would decode to < even when
using DecodeReserved

to solve this properly we now have two distinct states for the queries
represented by the actual objects we deal with.

our Query object is literal input and never transcodes

just before passing to KIO our Query is translated to a QUrlQuery and as
part of that comprehensively encoded through toPercentEncoding. this
should then ensure that what KIO deals with is indeed encoded in a
similar fashion to how a browser would do it, and how bugz expects it.

to ensure this works correctly the connection test has been extended
accordingly

BUG: 435442
FIXED-IN: 5.21.5


(cherry picked from commit d657b0e6)