chore(tests): standardize env setup for tests

[dreamorosi]

Description of your changes

This maintenance PR fixes an issue highlighted in #1083 by standardizing the setup phase of all the Jest tests in the workspace. This PR makes the AWS Region in which integration tests are run configurable by the user while also setting a default in case no preference is specified.

Details

This PR makes sure the all packages in the monorepo are using the now standard packages/*/tests/helpers/populateEnvironmentVariables.ts file which is referenced in the jest.config.js file and sets a number of standard environment variables throughout all tests.

One of these variables is the AWS_REGION one. Before this PR, some packages (Tracer and Logger) were always setting it while others (Metrics) weren't. This caused some tests to always run in an AWS Region regardless of user explicit settings while others stayed configurable.

The populateEnvironmentVariables.ts now checks if the user running the test has explicitly set the variable, if the variable is set it uses the value specified by the user, if it's not set is uses a default one (eu-west-1).

if (process.env.AWS_REGION === undefined && process.env.CDK_DEFAULT_REGION === undefined) {
  process.env.AWS_REGION = 'eu-west-1';
}

Other changes in this PR

Additionally, the PR also makes a small change to the jest.config.js files of each package to standardize the name & color shown in the console (housekeeping), i.e.:

Once merged, this PR fixes #1083.

How to verify this change

See results of automated checks below the PR, or successful run of the integration tests here.

Additionally, you can optionally run any of the integration tests locally using the command below & verify that they are in fact run in the AWS Region you specify:

AWS_REGION=eu-central-1 npm run test:e2e:nodejs18x -w packages/metrics

Related issues, RFCs

Issue number: #1083

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.