Possible issue observed in upstream dependency go-ieproxy

[wcs1only]

We've received reports from our users of possible hangs/crashes in go-ieproxy when running on Windows 10. From downstream issue (dapr/cli#707):

C:\Users\mcain>%userprofile%.dapr\bin\daprd.exe -version
Exception 0xc0000005 0x0 0x7ff9c85b0fff 0x1dcc4280000
PC=0x1dcc4280000

syscall.Syscall(0x7ff9c7eaadc0, 0x3, 0xc0005979c8, 0x0, 0x800, 0x0, 0x0, 0x0)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/runtime/syscall_windows.go:330 +0xe9
golang.org/x/sys/windows._LoadLibraryEx(0xc0005979c8, 0x0, 0x800, 0xc, 0xc, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/zsyscall_windows.go:2273 +0x96
golang.org/x/sys/windows.LoadLibraryEx(0x3d1bcfb, 0xb, 0x0, 0x800, 0xc000422b00, 0x30000, 0x5be42c0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/zsyscall_windows.go:2269 +0x9f
golang.org/x/sys/windows.loadLibraryEx(0x3d1bcfb, 0xb, 0x2030001, 0x2030000, 0x20, 0x422269e)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/dll_windows.go:407 +0x66
golang.org/x/sys/windows.(*LazyDLL).Load(0xc000511500, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/dll_windows.go:242 +0xca
golang.org/x/sys/windows.(*LazyProc).Find(0xc000511560, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/dll_windows.go:305 +0xc5
golang.org/x/sys/windows.(*LazyProc).mustFind(...)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/dll_windows.go:323
golang.org/x/sys/windows.(*LazyProc).Call(0xc000511560, 0xc000502150, 0x5, 0x5, 0x4223768, 0x2030001, 0x20, 0x42285d2)
C:/Users/runneradmin/go/pkg/mod/golang.org/x/sys@v0.0.0-20210225134936-a50acf3fe073/windows/dll_windows.go:347 +0x36
github.com/mattn/go-ieproxy.getUserConfigFromWindowsSyscall(0x0, 0x0, 0x0)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/ieproxy_windows.go:79 +0xa6
github.com/mattn/go-ieproxy.writeConf()
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/ieproxy_windows.go:33 +0x66
sync.(*Once).doSlow(0x5c365f8, 0x3e473b0)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/sync/once.go:68 +0xf7
sync.(*Once).Do(...)
C:/hostedtoolcache/windows/go/1.16.3/x64/src/sync/once.go:59
github.com/mattn/go-ieproxy.getConf(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/ieproxy_windows.go:23
github.com/mattn/go-ieproxy.GetConf(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/ieproxy.go:36
github.com/mattn/go-ieproxy.proxyMiddleman(0xc0008003e0)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/proxyMiddleman_windows.go:12 +0x486
github.com/mattn/go-ieproxy.GetProxyFunc(...)
C:/Users/runneradmin/go/pkg/mod/github.com/mattn/go-ieproxy@v0.0.0-20190610004146-91bb50d98149/GetProxyFunc.go:10
github.com/Azure/azure-pipeline-go/pipeline.newDefaultHTTPClient(0xa4e8a9)
C:/Users/runneradmin/go/pkg/mod/github.com/!azure/azure-pipeline-go@v0.2.1/pipeline/core.go:208 +0x2d
github.com/Azure/azure-pipeline-go/pipeline.init()
C:/Users/runneradmin/go/pkg/mod/github.com/!azure/azure-pipeline-go@v0.2.1/pipeline/core.go:202 +0x29

We have not been able to reproduce this issue ourselves, but it seems to resemble a known issue in upstream repo: mattn/go-ieproxy#17

[wcs1only]

So, part of the problem for us is that we're including azure-pipeline-go as a dependency, but a substantial majority of our customers aren't actually using it. This ieproxy function syscall is being invoked by the azure-pipeline-go modules at init() time before main is even run:
https://github.com/Azure/azure-pipeline-go/blob/master/pipeline/core.go#L202

Would you accept a patch to lazy call newDefaultHTTPClient() the first time you actually need it, rather than at module init() time? This might not solve the problem with the upstream dep, but it would solve our customers issue, given they aren't even using our Azure pipeline functionality.