ATO-2583: add feature flag to remove Orchestration OIDC lambda terraform deployments

[Ryan-Andrews99]

Wider context of change:

We previously deployed our lambdas into the old Authentication account and these were defined terraform. We would like to remove these to clean up some of the redundant unused resources in the auth account. To roll this out safely we would like to do this per environment.

What’s changed:

• Adds a feature flag, defaulted to true, to conditionally deploy the Orchestration OIDC lambdas defined in the terraform. The default behaviour here is to continue to deploy the lambdas unless overridden in the respective .tfvars file.
• Applies this flag to all the Orchestration OIDC lambdas and the dependant resources
• Adds new deployment triggers for the API Gateway to include previously introduced Orchestration integrations that might've been missed
• Turns off the deployments in dev envs

Manual testing

TODO:

• Deploy to a dev env with the flag turned true (ie still deploying stuff) - observe there is no difference in the deployed infra
• Turn the flag false - observe that there the OIDC lambdas are removed and that it deploys successfully

Checklist

• Lambdas have correct permissions for the resources they're accessing.

• Impact on orch and auth mutual dependencies has been checked.

• Changes have been made to contract tests or not required.

• Changes have been made to the simulator or not required.

• Changes have been made to stubs or not required.

• Successfully deployed to authdev or not required.

• Successfully run Authentication acceptance tests against sandpit or not required.

• Added new endpoints to local running (LocalOrchestrationApi.java) or not required.

Related PRs

[github-actions]

Java Tests Skipped

No Java files were changed in this pull request. Java tests will be skipped¹.

Any Java files that are changed in a subsequent commit will trigger the Java tests.

Footnotes

1. These tests will still show as passing in the PR status check, but will not actually have run. ↩

[Louisasa]

some questions

• do we need to change anything in sandpit.tfvars? I know it shouldn't be about but idk if it would break any deployments
• I think processing-identity is also ours?
• do we need to do anything with spot-response?

[Louisasa]

are you sure that this variable doesn't need to be added to all environments (even though it has a default)? just thinking back to the account management issue we had for the key rotation that failed because of some variables that were missing (and I've just checked, they did have defaults but one was a string so it might have been that idk)

[Louisasa]

I just want to double check that this doesn't technically create a new role (same with any other modules) and therefore cause any downtime? I don't think it should but I'm not entirely confident with terraform