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:

• [x] 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]

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.