Fixes #11891

This is a fix + refactor around how gh instantiates special HTTP clients for authentication purposes.

Below is a bit about the changes, and then instructions to verify the PR fixes the UNIX socket support during login.

Rationale

As a bit of context, almost every gh command uses f.HttpClient to get a new HTTP client instance. The client is created by cli/go-gh and is equipped with various layers of custom roundtrip overrides that take care of:

• Using UNIX sockets, if applicable
• Setting HTTP request headers (e.g. Authorization, User-Agent, Accept, or Content-Type)
  • The Authorization header is a bit tricky as it gets set at gh side.
• Adding verbose logging, if applicable

However, there were two places where a zero HTTP client (i.e. http.Client{}) was used instead of the central one; in auth login and in auth refresh. Both cases needed a plain HTTP client for their job and hence the workaround. The problem with these two outliers were:

1. UNIX socket config was ignored (the underlying issue)
2. The debug logging had to be duplicated
3. The User-Agent header was left to Golang's default Go-http-client/2.0
4. It wasn't testable

Changes

To fix 1 and 2, we needed to use the HTTP client created by cli/go-gh. Thankfully, there is an option named SkipDefaultHeaders in cli/go-gh, that we could just expose and use in cli/cli to create plain HTTP clients.

To resolve 3, we needed to pull up the HTTP client instantiation to the command level where we have the information about the gh version (i.e. f.AppVersion). However, if we were going to do that exactly at the command-level, then we had to something similar to what is done in the factory package, in httpClientFunc (here). The better approach seemed to pull up the changes to the factory package and then provide a plain counterpart to HttpClient in the factory struct. This is what's done in this PR; a new field, named PlainHttpClient is now added to factory.

Problem 4 is now resolved by adding an http.Client parameter to the OAuthFlow function.

Note that in the auth login command, both HTTP client (ordinary and plain) are used. The plain one is only used for the OAuth flow, and the rest of the API calls are made through the ordinary one. Although usages of the ordinary client could be changed to use the plain one (except for one case where a function in ssh add command package is called), but I decided to not do that in case we break things unknowingly; it'd probably be fine, though.

Testing UNIX socket support

Against GHES

It's best to make a testing directory and do these within:

1. Run make and copy the built binary to the testing directory.
2. Make a UNIX socket via socat:

   socat -v unix-listen:temp.sock,fork openssl:<HOST>:443

   This will block and show verbose logs, so keep the terminal window open. A UNIX socket, named temp.sock will be created in the working directory.
3. Open a new shell in the same directory and set the gh config directory once for all.

   export GH_CONFIG_DIR=$(pwd)
   export GH_DEBUG=api

4. Configure gh to use the UNIX socket:

   ./gh config set http_unix_socket temp.sock

5. Run auth login, select Other and enter the hostname:

   ./gh auth login -c

   Verify: the login process finished successfully and socat logs contain the same calls as in gh debug output (note the responses in socat logs are gzip-ed so it's fine if request bodies match). FWIW in the issue (gh auth ignores the http_unix_socket config value #11891), the OAuth flow calls didn't pass through the socket.
6. Run the followings one-by-one and verify:

   ./gh auth refresh -c
   ./gh auth refresh -c --scopes read:public_key
   ./gh auth refresh -c --remove-scopes read:public_key
   ./gh auth status

   Verify: the command finished successfully and the calls are visible on socat logs.
7. Run arbitrary non-auth commands and verify they work as expected:

   ./gh repo list
   ./gh api user
   ./gh issue list --repo <OWNER>/<REPO>
   ./gh pr list --repo <OWNER>/<REPO>

Against github.com

Testing against github.com is a bit tricky, since we use two different domains during the login process; github.com for OAuth and api.github.com for secondary calls (e.g. discovering scopes). It's best to make a testing directory and do these within:

1. Run make and copy the built binary to the testing directory.
2. Make a script, named hack.sh, to dynamically handle arbitrary domains:

   #!/bin/bash
   
   _request="$(timeout 1 cat)"
   _host="$(echo "$_request" | grep -iE "^Host: " | cut -d' ' -f2 | tr -d '\r\n')"
   
   if [ -z "$_host" ]; then
       echo -e "no Host header in request"
       exit 1
   fi
   
   echo "$_request" | openssl s_client -quiet -verify_quiet -tls1_3 -connect "$_host:443"

3. Make a UNIX socket and socat it to the script:

   socat -v unix-listen:temp.sock,fork system:'bash hack.sh'

   This will block and show verbose logs, so keep the terminal window open. A UNIX socket, named temp.sock will be created in the working directory.
4. Open a new shell in the same directory and set the gh config directory once for all.

   export GH_CONFIG_DIR=$(pwd)
   export GH_DEBUG=api

5. Configure gh to use the UNIX socket:

   ./gh config set http_unix_socket temp.sock

6. Run auth login and select GitHub.com for host:

   ./gh auth login -c

   Verify: the login process finished successfully and socat logs contain the same calls as in gh debug output (note the responses in socat logs are gzip-ed so it's fine if request bodies match). FWIW in the issue (gh auth ignores the http_unix_socket config value #11891), the OAuth flow calls didn't pass through the socket.
7. Run the followings one-by-one and verify:

   ./gh auth refresh -c
   ./gh auth refresh -c --scopes read:public_key
   ./gh auth refresh -c --remove-scopes read:public_key
   ./gh auth status

   Verify: the command finished successfully and the calls are visible on socat logs.
8. Run arbitrary non-auth commands and verify they work as expected:

   ./gh repo list
   ./gh api user
   ./gh issue list --repo cli/cli
   ./gh pr list --repo cli/cli