Description of problem:
pcs(1) honors HTTP(S)_PROXY/http(s)_proxy by accident (I don't think there
is a proper scenario to let pcs speak through a proxy) and thus fails when
running "pcs cluster auth node1 node2". Example:

$ export http_proxy=http://proxy.example.net:8080
$ export HTTP_PROXY=http://proxy.example.net:8080
$ export https_proxy=http://proxy.example.net:8080
$ export HTTPS_PROXY=http://proxy.example.net:8080

$ pcs cluster auth node1.example.net node2.example.net
Username: hacluster
Password: ********
Error: Unable to communicate with node1.example.net
Error: Unable to communicate with node2.example.net
$ 

While debugging this via strace(1), I noticed that pcs(1) connects here
to http://proxy.example.net:8080 and receives a "HTTP/1.0 403 Forbidden"
by the Squid. This again leads to a hardly readable stack trace within
strace output. The stack trace makes me believing that proxy setups for
pcs(1)are not intended - while pcs(1) seems to honor proxy environment
variables by accident. If this is really intended, then there should be
proper error messages - and of course no stack trace on "403 Forbidden"
replies by the proxy server.

Version-Release number of selected component (if applicable):
pcs-0.9.143-15.el7.x86_64

How reproducible:
Always, see above.

Actual results:
pcs(1) honors HTTP(S)_PROXY/http(s)_proxy by accident and thus fails at
"pcs cluster auth node1 node2".

Expected results:
pcs(1) should not honor environment variables related to proxy servers,
or proxy servers should be properly handled, especially "403 Forbidden".

Additional info:
Aside of this, the documentation likely should be updated to document this
behaviour (or did I overlook existing documentation regarding this?).