feat: use the reset api key resource block

[Aashiq-J]

Description

Release required?

• No release
• Patch release (x.x.X)
• Minor release (x.X.x)
• Major release (X.x.x)

Release notes content

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

For mergers

• Use a conventional commit message to set the release level. Follow the guidelines.
• Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
• Use the Squash and merge option.

[Aashiq-J]

/run pipeline

[Aashiq-J]

Skipping upgrade test because the old null resource block will be destroyed and new resource block for reset api key will be created. according to iks team, it shouldn't have any effect on existing cluster.

[Aashiq-J]

/run pipeline

[ocofaigh]

Moving to provider means we will loose the ability to check if key exists before resetting it. I think its worth remaining with the script due to this, because there is a limit on number of api keys any user can create, so we might hit the limit (thats one of the reasons I added it in the first place).
It also seems as if the provider is not doing any retries, so again our script would be the better option with retry and debug logging in it.

Unless we wanted to look into a combination of both? A script to check if key exists, and the result of that would trigger the reset. We might hit an issue though with the count not known before deploy time?