fix: url.search is a string so do not set it as a URLSearchParams

[achingbrain]

Updates the types to make transformSearchParams return a string and adds a test.

[hugomrdias]

its safer to work with a URLSearchParams instance, so why return a string here ? we can call .toString internally

[Gozala]

I also think that URLSearchParams is a better representation to work with.

[achingbrain]

I was trying to work around the way go-IPFS expects binary data to be URL encoded (see ipfs/kubo#7939 for context).

In a nutshell 0xFE (decimal 254) needs to be encoded as %FE and not %C3%BE, so I was doing the encoding myself but if you have to pass back a URLSearchParams instance, it'll re-encode the data, which makes it garbage on the server when it's decoded.

I don't think it's necessarily the way to go, since now everyone has to use a custom encoder/decoder - instead we should be able to pass base64 encoded data to the HTTP API if it has to go on the query string, but the fact that we have to @ts-ignore the assignment here seemed a bit weird.

URL.search is a string, and the return type of transformSearchParams gets turned into a string when it is assigned to URL.search so why not let the user return a string?

[hugomrdias]

im good with the internal change to assign strings to search just not the return type change.
I know transformSearchParams is basically just for our use but keeping the return type URLSearchParams will be at least a reminder to not manually encoded querystrings.

[achingbrain]

keeping the return type URLSearchParams will be at least a reminder to not manually encoded querystrings.

The thing is, I needed to manually encode a query string.

[hugomrdias]

ah lol, if we can avoid that lets ship this

[lidel]

Does not seem to be relevant anymore, feel free to open new one if needed.