Unify TF AWS provider configuration logic

[erhancagirici]

Description of your changes

refactors AWS client configuration logic with a single path.

Previously, the AWS config was following various paths due to:

• Terraform Provider Configuration does not support AssumeRoleChain with lengths > 1
• Terraform CLI was using the shared scheduler, which required configuration push-down
• eks.clusterAuth resource has a manual controller implementation, since it is not terraform-based
  To handle these paths, a native AWS configuration was being constructed along with the terraform configuration attributes.
  These were causing in a non-unified configuration path, and duplicated AWS STS API calls due to configuration being processed by the native method and Terraform provider configure for no-fork.

Since the TF CLI is removed all relevant configuration paths can be removed to simplify.

This PR:

• removal of Terraform configuration block preparation for CLI
  • TerraformSetup.Configuration is no more present
  • no push-down configuration
• AWS configuration and credential resolution is solely handled by native AWS config.
  • All auth methods resolves down to the final AccessKey and Secret key (temporary) credentials
  • other configuration such as AssumeRoleChain and custom endpoints are also handled by the AWS config
• move away from native TF Provider's Configure() method
  • this method had a potential to introduce unintended side effects and bugs, due to its singleton nature.
  • instead, the native TF configuration object is directly filled using the already-obtained native AWS config & credentials.
  • This reduces the extra AWS STS calls for GetCallerIdentity and AssumeRole operations.

As a result this leads to 50% reduction in STS calls made per reconcile. Further improvement to STS calls will follow with a cache implementation.

I have:

• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Tested manually with following ProviderConfig specifications:

• Static creds from secret
• Static creds from secret with AssumeRoleChain
• WebIdentity
• WebIdentity with AssumeRoleChain
• IRSA
• IRSA with AssumeRoleChain
• Upbound Auth (thanks @turkenf for the test)

[ulucinar]

The issue with the publish-artifacts job is a known one with the recent SSO changes. cc. @turkenf

[ulucinar]

Thank you very much @erhancagirici for cleaning up the AWS ProviderConfig code base and improving the situation with the number of per-MR STS calls the provider makes . Could you please also update the PR description with:

• The details of the changes this PR proposes
• The manual tests you did to verify these changes
• STS calls saved with these changes

We can also discuss briefly in the PR description the next iteration of planned improvements, where we would like to introduce a credential cache to further decrease the number of STS calls we make.

[ulucinar]

I feel like it will help simplifying this package if we just move GetAWSConfigWithProviderUsage to the ClusterAuth.eks controller package as currently, it's the only controller who uses this. If, in the future, we add another controller that needs this, then we can move this to a command module. What do you think?

[ulucinar]

Thank you @erhancagirici, lgtm.

[ulucinar]

The publish-artifacts job is expected to fail due to the recent Upbound SSO changes. We will need to fix the credentials related to that job.