Add support for workload identity federation

[sfc-gh-pmansour]

Please answer these questions before submitting your pull requests. Thanks!

1. What GitHub issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes SNOW-1967309: SNOW-1927956: Add support for workload identity federation #2202

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am modifying authorization mechanisms
   • I am adding new credentials
   • I am modifying OCSP code
   • I am adding a new dependency

3. Please describe how your code solves the related issue.

Adds a new authentication plugin called AuthByWorkloadIdentity, and plumbs it through the connection creation. This relies on a few parameters:

• authenticator: This is an existing parameter, but now has a new supported value WORKLOAD_IDENTITY.
• workload_identity_provider: A new optional parameter that can describe how to load the workload identity credential. Can be AWS, AZURE, GCP, OIDC or None. If this is set to None, it will attempt to auto-discover a credential based on the environment.
• workload_identity_entra_resource: A new optional parameter, to be used when targeting a custom Azure Entra ID application as the resource, for example in a sovereign cloud.

There is a broad suite of tests for all the new functionality, including a set of new fixtures that fake the behavior of the major CSP metadata services.

Usage examples:

# To auto-discover a credential
connect(account="my_account", authenticator="WORKLOAD_IDENTITY")

# To look specifically for an AWS credential
connect(account="my_account", authenticator="WORKLOAD_IDENTITY", workload_identity_provider="AWS")

# To use an OIDC token from the given file path
connect(account="my_account", authenticator="WORKLOAD_IDENTITY", token_file_path="/service-account-token")

These changes cannot be used yet as the backend support is not ready. They're gated by a new environment variable SF_ENABLE_EXPERIMENTAL_AUTHENTICATION which must be set.

Also note that the default Entra ID application resource is not ready yet, so I used a placeholder value that's guaranteed to fail in reality. This will be updated in a follow-up PR once that application is ready.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[sfc-gh-dbasavin]

Looks great!

[sfc-gh-pmansour]

I have read the CLA Document and I hereby sign the CLA

[sfc-gh-jkasten]

Awesome, Peter!

[sfc-gh-jkasten]

[no action required] Is there any precedent for the time out value?

On first glance, a timeout of 3 seconds seems pretty tight to me for a request that can't be cached. I am guessing this is for the auto-discovery case and if we expand it we might hang unnecessarily? I would naturally be tempted to expand the timeout for the non-auto discovery case, but perhaps that adds more complexity than it is worth.

I was unable to find any SLOs for latency on the metadata services. I know that this should be a local request and the cloud would break if this were to go down. I am sure it is OK and hopefully there are retries along a real application.

[sfc-gh-jkasten]

Suggested change

	in the future we could have, for example, multiple AttestationProviders that all fetch an OIDC token.
	in the future we could have, for example, multiple AttestationProviders that all fetch an OIDC ID token.

nit/optional