update proxy setting on registry changes

[wfurt]

update proxy configuration on registry changes on Windows. That for example allows to start Fiddler and start capturing traffic without need to restart the process. It can of course also pick changes user does directly via Setting widget.

fixes #46910 and contributes to #95252.
It does not implement new API #95252 proposed but it seems to fix the use case it is describing.
Perhaps it can be closed as well @ManickaP?

Note that this does not apply to existing connections. e.g. the updated setting applies only when new connection is needed. If that is problem, it can perhaps be mitigated by either idea or absolute time on connection pool..

It also cannot detect changes to PAC or cases when something changes inside "auto" but there is no registry change.

[jkotas]

Is it possible for multiple UpdateConfiguration() callbacks to run in parallel if there are multiple registry edits done in sequence?

We may want to ensure that the most recent UpdateConfiguration wins in this case.

[wfurt]

The notifications do not have content. e.g. I think it would work just fine as long as the updates would finish in sequence they started.

The problem may be if let say there are part A and B. B get updated and that starts update reading old A. A updates, new config update starts and finishes before first update is done. The first task may be winner writing older configuration.

If we feel this is concern we have several options. We can simply lock the proxy object in the callback. Since that is only one place the only contention would be registry notification. But I'm not sure if that can cause any troubles for the thread pool. We can also update ThreadPool.RegisterWaitForSingleObject to fire only once but then we need new registration every time and I don't know how expensive that is (relative to all the other processing) I was also originally thinking about swapping the order of RegNotifyChangeKeyValue and UpdateConfiguration but I think we may miss some notifications in that case.

[jkotas]

I do not see a problem with taking the lock.

[ManickaP]

It does not implement new API #95252 proposed but it seems to fix the use case it is describing.
Perhaps it can be closed as well @ManickaP?

We didn't want to implement new API, we wanted to change the behavior which at the moment is fetch once per whole process lifetime. So we also talked about rechecking environment variables every time you call GetSystemProxy, which this PR doesn't handle AFAICT.

[wfurt]

all tests failures are known issues. This is ready for another review round.

[rzikm]

LGTM