fix: export names of client secrets must be unique, add aws_region to client secrets in secrets manager

[anayeaye]

What

• Fixes The Outputs section contains duplicate Export names by making client secret id export names unique (and more specific). New export names are:
  • {stack_name}-workflows-client-secret-id for the service client secret used by airflow
  • {stack_name}-programmatic-client-secret-id for the use password token generating client used for endpoints that grant tokens (ingest-api, maybe workflows-api in future)
  • {stack_name}-identity-provider-secret-id for the optional data managers group (not used in higher environments)
• Adds aws_region to each stored client secret
• cicd pr and deployment actions on main branch now triggers cdk diff and deployment on a stack named veda-auth-stack-staging

How tested

Testing under way in dev stack. I will confirm

• aws_region is included and correct in secrets manager secrets for clients
• values of programmatic client secret are unchanged (or I will cycle these changes to the dev backend)
• user password token generation works as expected in ingest-api/token endpoint

Manual administrative steps needed after merge to main

• Update the veda-backend env variable VEDA_CLIENT_ID with the programmatic client id generated for the new veda-auth-stack-staging
• Update veda-architecture wiki information about the new veda auth programmatic client for staging
• Update veda-architecture wiki with information to begin tracking legacy stacks that will be deprecated (veda-stac-ingestor-* and veda-auth-stack-uah). Step one in planning how we will sunset these.

[slesaad]

🙇

[anayeaye]

Note The client id of the dev stack did change (the user pool and users were persisted). I manually tested the dev ingest api by updating the client id in the console and, after testing, I updated the client id in the veda-backend-uah-dev-env configuration.

The dev auth stack has not been redeployed for over a year and the client id change may not be related to this change BUT to be safe I have opened another PR to make sure we don't impact the veda-auth-stack-uah client ID which would have multiple downstream impacts. This PR will create a new veda-auth-staging stack so that we don't have to worry about cycling possible client id changes to veda-stac-ingestor.