Prepared Requests: Replaced url still gets encoded

As suggested in #1454, #5739 and #3077, if one wants to stop `requests` from encoding request query parameters, the [PreparedRequest-flow](https://docs.python-requests.org/en/master/user/advanced/#prepared-requests) should be used. Replacing the url works, but when actually performing the request, the URL still gets encoded.

## Expected Result
Calling `Session.send` for an instance of `PreparedRequest` uses exactly the specified URL of the prepared request and not further encodes it.

## Actual Result
Calling `Session.send` for an instance of `PreparedRequest` automatically encodes the URL of the prepared request.

## Reproduction Steps

```python
from requests import Request, Session

# use requestcatcher to see which url got called
url = "https://tm97.requestcatcher.com/test/"
weird_characters = "[]%$"

s = Session()

req = Request('GET', url)
prepped = req.prepare()

prepped.url = url + weird_characters

resp = s.send(prepped)

```
```python
>>> print(prepped.url)
https://tm97.requestcatcher.com/test/[]%$
```
```
# actual observed URL on requestcatcher

GET /test/%5B%5D%25$ HTTP/1.1
Host: tm97.requestcatcher.com
Accept-Encoding: identity
User-Agent: python-urllib3/1.26.6
```
As you can see the special characters get encoded automatically. To make sure that requestcatcher itself does not do any encoding, I sent the same request using `wget` and it did not encode anything there.

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.2"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.8.10"
  },
  "platform": {
    "release": "5.11.0-27-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.26.0"
  },
  "system_ssl": {
    "version": "1010106f"
  },
  "urllib3": {
    "version": "1.26.6"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}

```

Let's look through the flow at the point at which you're entering.

[`Session.send`](https://github.com/psf/requests/blob/b0e025ade7ed30ed53ab61f542779af7e024932e/requests/sessions.py#L626) off-loads the request to the HTTPAdapter it's found to use and doesn't normalize URLs: https://github.com/psf/requests/blob/b0e025ade7ed30ed53ab61f542779af7e024932e/requests/sessions.py#L655 . [`HTTPAdapter.send`](https://github.com/psf/requests/blob/b0e025ade7ed30ed53ab61f542779af7e024932e/requests/adapters.py#L394) uses the standard library to [parse](https://github.com/psf/requests/blob/b0e025ade7ed30ed53ab61f542779af7e024932e/requests/adapters.py#L329) the URL to pass onto urllib3 which you can verify locally doesn't normalize anything to an RFC3986 valid URI

```
>>> url = "https://tm97.requestcatcher.com/test/"
>>> weird_characters = "[]%$"
>>> import urllib.parse
>>> urllib.parse.urlparse(url + weird_characters)
ParseResult(scheme='https', netloc='tm97.requestcatcher.com', path='/test/[]%$', params='', query='', fragment='')
>>> scheme, netloc, path, params, query, fragment = _
>>> path
'/test/[]%$'
>>> urllib.parse.urlunparse((scheme, netloc, path, params, query, ''))
'https://tm97.requestcatcher.com/test/[]%$'
```

And then after that, the rest of [`send`](https://github.com/psf/requests/blob/b0e025ade7ed30ed53ab61f542779af7e024932e/requests/adapters.py#L422-L533) is passing the request information to urllib3 to handle. At that point, you can see that [urllib3](https://github.com/urllib3/urllib3/blob/dbd0b85b3a9d852c817e5c33f1ff9b0af8d0aae9/src/urllib3/connectionpool.py#L649) ensures it's a valid path per all specifications (WHAT-WG's latest specifications, RFC 3986 before it, etc.). This is not a bug strictly in Requests at this point

@sigmavirus24 Thank you for the explanantion. While I agree that is not a bug of requests specifically, you closed #5739 with the suggestion to use the prepared request flow. However, as demonstrated in this issue, the prepared request flow does not work for urls.

So I guess this cannot be handled by requests right now and I have to switch to another library? As this issue is rightfully closed, I would suggest re-opening #5739 and continuing the discussion there. 

> . While I agree that is not a bug of requests specifically, you closed #5739 with the suggestion to use the prepared request flow. However, as demonstrated in this issue, the prepared request flow does not work for urls.

It did work in #5739. The bug should be opened with urllib3 to provide an escape hatch here if desired.