baseurl does not properly handle http GET query parameter

Describe the bug

When utilizing a baseurl that is hosted with access control measures in place, tdnf has difficulty attempting to properly append paths to the baseurl.

E.g.,
A package repository is hosted in a cloud service and access to anything within the cloud storage is handled through passing of http query parameters
(For example, in https://github.com/vmware/tdnf/issues/new?assignees=&labels=bug&projects=&template=bug-report.yml url, the substring ?assignees=&labels=bug&projects=&template=bug-report.yml is the query parameter)
In the cloud storage situation, the unauthenticated baseurl may look like: foo.cloudservice.storage.com/reporoot and the authenticated baseurl will look like: foo.cloudservice.storage.com/reporoot?<authenticationtoken>.

This authentication token must be appended to every HTTP get request when interacting with the cloud storage service.

In TDNF, there is no handling of this query substring, so the final path will get appended after this query parameter.

foo.cloudservice.storage.com/reporoot?<authenticationtoken>/repodata/repomd.xml
instead of
foo.cloudservice.storage.com/reporoot/repodata/repomd.xml?<authenticationtoken>

This prevents the use of tdnf with secured package repositories.

When a baseurl contains an http query parameter, tdnf fails to retrieve the repomd.xml and will cease to function, causing a non-zero exit code.

Reproduction steps

1. Create a private container in Azure Storage (Please reach out if I can help with this)
2. Create a .repo file that points to the authenticated baseurl of the storage account
3. Attempt to call tdnf makecache
   ...

Expected behavior

tdnf makecache, and all other tdnf commands should behave the same as with an unauthenticated baseurl

Additional context

No response

Start by locating the code that constructs repository request URLs and handles HTTP GETs, then reproduce the issue with a baseurl containing a query parameter and tdnf makecache. Done means the query token remains after the appended repository path, and authenticated repositories work as unauthenticated ones do.