refactor: consume dynamic env vars from SSM rather than env vars [CHI-2897]

[GPaoloni]

This PR completes the migrations of https://github.com/techmatters/infrastructure-config/pull/407 and techmatters/flex-plugins#2673.

Description

This PR

• Adds a "dependency injection" logic to our auth functions (packages/twilio-worker-auth/src/twilioWorkerAuthMiddleware.ts): authTokenLookup and staticKeyLookup are required as parameters, with no "defaults" being configured.
• Defines SSM cache helpers in HRM core that read the required parameters and caches them. This is used as the lookup functions mentioned above, by using auth_token and static_key parameters.
• Above SSM cache is also used to lookup permissions config, by using permission_config parameter.
• HRM and Resources services now expect to be given lookup functions that will then be used in auth. Both are being passed the same defaultAuthSecretsLookup (defined in HRM core), but should be rather trivial to pass the resources secrets once this service is isolated.

Note: all of the above is "added on top" of the environment variables. If the env vars are still provisioned via the env vars file, nothing will change, except that there's some extra "async" code around.
Once https://github.com/techmatters/infrastructure-config/pull/410 is applied, and the env vars are not provisioned from S3 anymore, the SSM reading logic will kick in.

Checklist

• Corresponding issue has been opened
• New tests added
• Feature flags / configuration added

Verification steps

Is easier to deploy to development and test there. Configuring local environment to test this changes is time consuming. I'm happy to explain how to, if that's really desired, since I can quickly share the needed secrets.

AFTER YOU MERGE

1. Cut a release tag using the GitHub workflow. Wait for it to complete and notify in the #aselo-deploys Slack channel.
2. Comment on the ticket with the release tag version AND any additional instructions required to configure an environment to test the changes.
3. Only then move the ticket into the QA column in JIRA

You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P

[stephenhand]

Just the naming thing. Looks good otherwise

[stephenhand]

Can we revert this back to the correct file naming convention? i.e. camel case

[stephenhand]

In fact, given it's specialised nature, perhaps we could call it something like ssmConfigurationCache?