Ignore proxy for cloud metadata retrieval

[mhashizume]

Prior to this commit when a user set the http_proxy environment variable, the Net::HTTP#new in the HTTP resolver would use it when establishing new connections. While this is the desired behavior in most cases, this also interfered with fetching cloud metadata for services like AWS and GCP.

Facter had previously dealt with this behavior in earlier versions (2.x) starting with 23bf7e5, but that was lost during Facter's transition from C++ back to Ruby.

This commit sets Net::HTTP#new's p_addr (proxy address) argument to nil when Facter detects that the http_proxy environment variable is present when attempting to resolve cloud service metadata.

[mhashizume]

I think this is introducing some unwanted behavior related to positional and keyword arguments.

Some of the methods being called here use a hash as what's intended to be a positional argument but, with the addition of keyword arguments in this PR, older Rubies seem to now misinterpret the keys in that hash as individual keyword arguments.

For example in the ec2 resolver, the headers and timeouts arguments now seem to get wrongly interpreted as keyword arguments:

facter/lib/facter/resolvers/ec2.rb

Lines 52 to 56 in dbfb450

	def get_data_from(url)
	headers = {}
	headers['X-aws-ec2-metadata-token'] = v2_token if v2_token
	Facter::Util::Resolvers::Http.get_request(url, headers, { session: determine_session_timeout })
	end

I think we can resolve this by using strings instead of symbols in these positional hash arguments and being explicit about the hash syntax({ 'foo' => 'bar' } instead of { foo: 'bar'}), but that may have other implications. I'll do more testing and research on this.

[mhashizume]

When attempting to add new keyword arguments to the get_request and put_request methods, I'm running into issues with different versions of Ruby and how they deal with the separation of positional and keyword arguments.

The last argument of these methods (timeouts) is an optional hash that uses symbols as keys. In Ruby < 3.0, Ruby interprets the keys in the timeouts hash as keyword arguments if we add any keyword arguments to the get_request/put_request methods.

For example, running this rspec test on Ruby 2.7.8:

  1) Facter::Util::Resolvers::Http when windows #get_request behaves like a http request on windows when timeout is configured uses the desired value
     Failure/Error:
       def get_request(url, headers = {}, timeouts = {}, http_port: 80, proxy_addr: DEFAULT_HOST)
         make_request(url, headers, timeouts, 'GET', http_port, proxy_addr)

     ArgumentError:
       unknown keyword: :connection
     Shared Example Group: "a http request on windows" called from ./spec/facter/util/resolvers/http_spec.rb:163
     # ./lib/facter/util/resolvers/http.rb:32:in `get_request'
     # ./spec/facter/util/resolvers/http_spec.rb:131:in `block (4 levels) in <top (required)>'

Ruby >= 3.0 properly separates positional and keyword arguments:

$ bundle exec rspec ./spec/facter/util/resolvers/http_spec.rb:131
Run options: include {:locations=>{"./spec/facter/util/resolvers/http_spec.rb"=>[131]}}
..

Finished in 0.19973 seconds (files took 8.66 seconds to load)
2 examples, 0 failures

But because we still support Facter on Ruby >= 2.5, we need to account for Ruby < 3.0.

We could solve this issue by making sure that the keys in the timeouts hash are strings intead of symbols. However, other parts of the code access values in the hash by looking for symbol keys specifically (like in here) and get_request/put_request are public methods. The fact that those methods are public mean that while I think additive changes like new keyword arguments are probably okay, changes or removals risk breaking things for any users who may rely on those methods.

I'm going to instead try to implement this with a boolean positional argument instead which, while isn't as clean, seems easier to implement across Ruby versions and retains compatibility with these public methods.

See also: https://www.fastruby.io/blog/fix-sneaky-argument-error-when-upgrading-ruby.html

[mhashizume]

Closing in favor of #2704