commit b8d1d88658253bcd6d2522d337b77e318b3420a2
author Nicolas Arciniega <niarci@microsoft.com> Wed Jul 29 18:29:00 2020
committer Commit Bot <commit-bot@chromium.org> Wed Jul 29 18:29:00 2020
tree 5633cd8a4e0dd815d160970401a682d77afd8389
parent 72b88876ea4282526be0cf30216d273b78d91be1

Reland "Implement the WindowsSystemProxyResolutionService/Request"

This is a reland of 33f234e709a171acce00d6c4103b9730db303332

This change differs from the original change in that:
- This one dynamically loads WinHttp functions that are not supported
  in Windows 7 and below (see WinHttpProxyResolverFunctions).
- This change fixes a string copy issue in the unit tests.

This change creates a functional proxy resolver for Windows that relies
on WinHttp APIs. This is not in its final state, though. This CL
represents the simplest, least-work way to implement this proxy
resolution service. Work still to come includes:
- Complete NetLogs
- Better error reporting from WinHttp APIs
- Proxy Delegate
- Proxy retry info
- Assurance that the proxy configs we're receiving are from the system

The WindowsSystemProxyResolutionService is the object that external
callers use to resolve a proxy. These callers can keep track of the
status of this proxy resolution via a ProxyResolutionRequest,
implemented here as a WindowsSystemProxyResolutionRequest. The request
object is mainly intended to kick off a specific proxy resolution and
report a result via a caller-provided callback. Both of these objects
deal with a WindowsSystemProxyResolver.

The WindowsSystemProxyResolver is a new class that does all the required
interfacing with WinHttp APIs. It is a reference counted object created
by the WindowsSystemProxyResolutionService. Once created, it is used for
the lifetime of the WindowsSystemProxyResolutionService. Throughout that
time, the Resolver indirectly keeps a WinHttp session handle open. Each
WindowsSystemProxyResolutionRequest is given a reference to the new
resolver. When the Request object attempts to resolve a proxy for a
given URL, it'll call into the Resolver object. Under the hood, the
Resolver object creates a handle for the proxy resolution and runs the
async call to WinHttp. At any time, the Request object can choose to
ignore a pending result from the Resolver (ex: shutdown). The Resolver
object must be reference counted because async WinHttp calls call back
directly into the Resolver object, so it needs to stay alive as long as
we're waiting for an async response from WinHttp.

Another new object is the WinHttpAPIWrapper, which is just a thin
wrapper over WinHttp APIs which we use to enable easier testing and
to simplify some interactions with WinHttp. A WinHttpAPIWrapper is owned
by a WindowsSystemProxyResolver. The Resolver object is the only object
that should interact with the Wrapper object in any meaningful way.
Internally, the WinHttpAPIWrapper keeps track of the opened WinHttp
session handle that we're using for the lifetime of the Resolver object.

This feature is only supported in Windows 8 and above. Prior versions
of Windows will not be able to instantiate the
WindowsSystemProxyResolutionService. Loading the right functions for
Windows 8+ is handled by the WinHttpProxyResolverFunctions singleton.

This change includes tests for the WindowsSystemProxyResolver layer (by
mocking out the WinHttpAPIWrapper) and the
WindowsSystemProxyResolutionService (by mocking out the
WindowsSystemProxyResolver).

Bug: 1032820
Change-Id: I1075e5c918e5aa14f7317853e6a39103ad9383d2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2310672
Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Nicolas Arciniega <niarci@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#792787}