Proxy PvDs: Client IPs as a matching rule

[JamesTaft]

          I think proxy-specific priority is too crude as priority might differ depending on the destination. Also it does not allow us to communicate possibility for client to do direct fallback.

I plan to submit a PR by the end of this week describing my previous suggestion with list of proxies per destination group.

I am not a big fan of encoding client IP restrictions in the PvD for a number of reasons:

• Client could be behind NAT and does not know its IP
• Client could have multiple interfaces some of which could have overlapping IPs
• There are potential privacy and security risks associated with specific client IP hints

If client-specific configuration is needed, PvD contents should be provided depending on client IP from PvD hosting service perspective - similarly to how it is done today for PAC files. I'll submit a corresponding text in a PR to clarify this.

Originally posted by @yaroslavros in #262 (comment)

In my experience, ClientIP is frequently used to direct specific types or locations of clients to their own set of proxies or incoming port.
Use cases:
Unauthenticated server traffic that uses a different proxy port and is assigned a very restrictive policy.
Directing to the nearest proxy cluster based on known internal IP ranges.

While I agree that this should be handled by the PvD hosting service, it is still a deprecation of functionality. There is no guarantee their PvD hosting service has the ability or visibility to modify the PvD on a per client basis. Some orgs use internal NATing to work around overlapping IP space, for example.

"matchClientIP" could be added as a key.

The multi-interface IP issue already exists with PAC files so it's not a new complexity. It's actually an improvement because this isn't freeform javascript so the security concerns are lowered and more controllable by the OS/Browser.