Prevent unnecessary should_bypass_proxies checks in rebuild_proxies


Signed-off-by: David Black <dblack@atlassian.com>

I noticed https://github.com/psf/requests/pull/5893 prior to pushing the exact same fix for the performance regression noticed that I had made locally. This PR extracts the re-building proxies performance regression fix from https://github.com/psf/requests/pull/5893 to have it be in its own pr/change . cc  
@omermizr 

@dbaxa The only thing that looks kinda wonky here to me is that `rebuild_proxies` has a side effect of removing the `Proxy-Authorization` header (see https://github.com/psf/requests/issues/5888). It's probably not the intended behavior (as stated in the issue), but I'm not familiar with the considerations.
Anyway, if it shouldn't do that - then it shouldn't do that even when `proxies` is not set, and if it should do that - after this PR we no longer do. So this introduces inconsistent behavior...

@omermizr I am not sure I entirely follow what you have said. 

I'll re-phase what I think you are suggesting here & add some of my own understanding - which might help -

1. If proxies have been set we don't need to call `rebuild_proxies`
2. If proxies have been set we do call `rebuild_proxies`
3. Calling `rebuild_proxies` removes the `Proxy-Authorization` header
4. So if we explicitly set `proxy` information and `Proxy-Authorization` has been explicitly set - we won't remove the `Proxy-Authorization` header  <- this sounds like it would work as expected to me, unless the header should be removed if we are to bypass proxying later. 
5. `rebuild_auth` Does not interact with the `Proxy-Authorization` header but it does interact with a `Authorization` header
6. `rebuild_proxies` does remove any explicitly set `Proxy-Authorization` header - as it will try to fill it in from/via `get_auth_from_url` (if a defined proxy has username & password information as part of the url - it will attempted to be used). 
7. `should_bypass_proxies` seems to be the main `slow path` that we should be avoiding if proxies have explicitly been set.

Therefore imho the better fix is to do one of the following:
* Provide a fast(er) path inside of `rebuild_proxies` such that we do not call `should_bypass_proxies` - at least not when `proxies` have been explicitly provided and/or possibly not when `trust_env` is set to false (as we don't trust the env and so there is no need to examine the environment) 
* cache and or make obtaining proxies from `env` faster (the maintainers seem not to want to do this)
* Do as you did for https://github.com/psf/requests/pull/5893/files and have `rebuild_auth` interact with proxy auth header - but this modifies public api code 


Not removing `Proxy-Authorization` when proxy information has been explicitly set is an issue as we might not end up selecting the proxy for the given scheme iirc.

Before the revised changed ->
```         20382240 function calls (20362186 primitive calls) in 10.494 seconds

   Ordered by: internal time
   List reduced from 543 to 30 due to restriction <30>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   950001    0.583    0.000    1.435    0.000 /usr/lib/python3.9/os.py:674(__getitem__)
  1050005    0.519    0.000    2.563    0.000 /usr/lib/python3.9/_collections_abc.py:848(__iter__)
  1840000    0.372    0.000    0.632    0.000 /usr/lib/python3.9/os.py:758(decode)
    10000    0.341    0.000    2.815    0.000 /usr/lib/python3.9/urllib/request.py:2486(getproxies_environment)
   950001    0.330    0.000    0.525    0.000 /usr/lib/python3.9/os.py:754(encode)
        1    0.310    0.310    0.310    0.310 {method 'do_handshake' of '_ssl._SSLSocket' objects}
  2090069    0.289    0.000    0.289    0.000 {method 'decode' of 'bytes' objects}
  1900120    0.269    0.000    0.424    0.000 {built-in method builtins.isinstance}
   940000    0.264    0.000    0.569    0.000 /usr/lib/python3.9/os.py:697(__iter__)
    70004    0.210    0.000    0.634    0.000 /usr/lib/python3.9/_collections_abc.py:932(update)
        1    0.178    0.178    0.178    0.178 {method 'read' of '_ssl._SSLSocket' objects}
  1530141    0.175    0.000    0.175    0.000 {method 'lower' of 'str' objects}
  ...
```

After the revised change ->
```
         10082240 function calls (10062186 primitive calls) in 6.860 seconds

   Ordered by: internal time
   List reduced from 536 to 30 due to restriction <30>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.294    0.294    0.294    0.294 {method 'do_handshake' of '_ssl._SSLSocket' objects}
    70004    0.201    0.000    0.606    0.000 /usr/lib/python3.9/_collections_abc.py:932(update)
   910120    0.192    0.000    0.336    0.000 {built-in method builtins.isinstance}
        1    0.189    0.189    0.189    0.189 {method 'read' of '_ssl._SSLSocket' objects}
        1    0.145    0.145    0.145    0.145 {method 'connect' of '_socket.socket' objects}
        ...
```

*bump* cc  @sigmavirus24 / @nateprewitt

@nateprewitt can we merge this ?

I think this is alright as a minor optimization, but doesn't address either of the original issues. I'd like to get those refactored and resolved before we merge anymore changes into the method.

@nateprewitt imho it is slightly more than a minor optimisation (for certain use cases) & I have a concern that fixing/re-factoring the related code is likely to be complex and take a fairly long time. I am not sure how much https://github.com/psf/requests/pull/5894#issuecomment-889508604 applies to what you feel we should have as the result though. Mainly this part ->
> have rebuild_auth interact with proxy auth header - but this modifies public api code


> @nateprewitt imho it is slightly more than a minor optimisation (for certain use cases) 

Sure, I was conveying it doesn't affect the hot path for the average user. There may be larger improvements for more niche uses.

> I have a concern that fixing/re-factoring the related code is likely to be complex and take a fairly long time. I am not sure how much #5894 (comment) applies to what you feel we should have as the result though.

That may be true, I've left [my thoughts](https://github.com/psf/requests/pull/5893#discussion_r692463139) on moving forward in the issue, but I don't know if we've arrived at a consensus. Either way, #5893 is a blocker for the next release of Requests, so merging this now or later has no effect on when it's available publicly.

Hey @dbaxa, now that #5924 is merged would you mind rebasing this change onto the new `resolve_proxies` function in `utils.py`?