Move usage of config struct in auth login (#4310)

## Changes
Refactors the `auth login` command to make it clear that the config
struct is only needed for making a request to configure clusters when a
`--configure-clusters` flag is passed.

The request itself is changed from using `databricks-cli` auth type
which creates a child CLI process to using the newly minted token
directly in a custom auth type.

## Why
Reduce confusion about what part of the SDK is used by the CLI in the
auth login command. This is being done as a part of an effort to make
the `databricks-cli` auth type consistent across the SDKs by having the
Go SDK also rely on the CLI's `auth token` command like the Java and
Python SDKs.

## Tests
 - Existing tests for auth login pass.
- Added new acceptance tests, generating their outputs by running on
main.
 - Manually tested that passing `--configure-cluster` flag works

<!-- If your PR needs to be included in the release notes for next
release,
add a separate entry in NEXT_CHANGELOG.md as part of your PR. -->

---
NO_CHANGELOG=true

---------

Co-authored-by: Renaud Hartert <renaud.hartert@databricks.com>

Author: tejaskochar-db

acceptance/cmd/auth/login/custom-config-file/out.databrickscfg

@@ -0,0 +1,6 @@
+; The profile defined in the DEFAULT section is to be used as a fallback when no profile is explicitly specified.
+[DEFAULT]
+
+[custom-test]
+host      = [DATABRICKS_URL]
+auth_type = databricks-cli

acceptance/cmd/auth/login/custom-config-file/out.test.toml

@@ -0,0 +1,21 @@
+
+=== Initial custom config file (with old host)
+[custom-test]
+host = https://old-host.cloud.databricks.com
+auth_type = pat
+token = old-token-123
+
+=== Login with new host (should override old host)
+>>> [CLI] auth login --host [DATABRICKS_URL] --profile custom-test
+Profile custom-test was successfully saved
+
+=== Default config file should NOT exist
+OK: Default .databrickscfg does not exist
+
+=== Custom config file after login (old host should be replaced)
+; The profile defined in the DEFAULT section is to be used as a fallback when no profile is explicitly specified.
+[DEFAULT]
+
+[custom-test]
+host      = [DATABRICKS_URL]
+auth_type = databricks-cli

acceptance/cmd/auth/login/custom-config-file/output.txt

@@ -0,0 +1,39 @@
+sethome "./home"
+
+# Use a fake browser that performs a GET on the authorization URL
+# and follows the redirect back to localhost.
+export BROWSER="browser.py"
+
+# Set custom config file location via env var
+export DATABRICKS_CONFIG_FILE="./home/custom.databrickscfg"
+
+# Create an existing custom config file with a DIFFERENT host.
+# The login command should use the host from --host argument, NOT from this file.
+# If the wrong host (from the config file) were used, the OAuth flow would fail
+# because the mock server only responds for $DATABRICKS_HOST.
+cat > "./home/custom.databrickscfg" <<EOF
+[custom-test]
+host = https://old-host.cloud.databricks.com
+auth_type = pat
+token = old-token-123
+EOF
+
+title "Initial custom config file (with old host)\n"
+cat "./home/custom.databrickscfg"
+
+title "Login with new host (should override old host)"
+trace $CLI auth login --host $DATABRICKS_HOST --profile custom-test
+
+title "Default config file should NOT exist\n"
+if [ -f "./home/.databrickscfg" ]; then
+    echo "ERROR: Default .databrickscfg exists but should not"
+    cat "./home/.databrickscfg"
+else
+    echo "OK: Default .databrickscfg does not exist"
+fi
+
+title "Custom config file after login (old host should be replaced)\n"
+cat "./home/custom.databrickscfg"
+
+# Track the custom config file to surface changes
+mv "./home/custom.databrickscfg" "./out.databrickscfg"

acceptance/cmd/auth/login/custom-config-file/script

@@ -0,0 +1,3 @@
+Ignore = [
+    "home"
+]

acceptance/cmd/auth/login/custom-config-file/test.toml

@@ -0,0 +1,6 @@
+; The profile defined in the DEFAULT section is to be used as a fallback when no profile is explicitly specified.
+[DEFAULT]
+
+[override-test]
+host      = [DATABRICKS_URL]
+auth_type = databricks-cli

acceptance/cmd/auth/login/host-arg-overrides-profile/out.databrickscfg

@@ -0,0 +1,16 @@
+
+=== Initial profile with old host
+[override-test]
+host = https://old-host.cloud.databricks.com
+
+=== Login with positional host argument (should override profile)
+>>> [CLI] auth login [DATABRICKS_URL] --profile override-test
+Profile override-test was successfully saved
+
+=== Profile after login (host should be updated)
+; The profile defined in the DEFAULT section is to be used as a fallback when no profile is explicitly specified.
+[DEFAULT]
+
+[override-test]
+host      = [DATABRICKS_URL]
+auth_type = databricks-cli

acceptance/cmd/auth/login/host-arg-overrides-profile/out.test.toml

@@ -0,0 +1,25 @@
+sethome "./home"
+
+# Create an existing profile with a DIFFERENT host
+cat > "./home/.databrickscfg" <<EOF
+[override-test]
+host = https://old-host.cloud.databricks.com
+EOF
+
+title "Initial profile with old host\n"
+cat "./home/.databrickscfg"
+
+# Use a fake browser that performs a GET on the authorization URL
+# and follows the redirect back to localhost.
+export BROWSER="browser.py"
+
+# Login with profile but provide a different host as positional argument
+# The positional argument should override the profile's host
+title "Login with positional host argument (should override profile)"
+trace $CLI auth login $DATABRICKS_HOST --profile override-test
+
+title "Profile after login (host should be updated)\n"
+cat "./home/.databrickscfg"
+
+# Track the .databrickscfg file that was created to surface changes.
+mv "./home/.databrickscfg" "./out.databrickscfg"

acceptance/cmd/auth/login/host-arg-overrides-profile/output.txt

@@ -0,0 +1,3 @@
+Ignore = [
+    "home"
+]