feat(cat-voices): build time env and runtime config

[damian-molinski]

Description

This PR allows frontend environment to be configured in build-time. It leads other configuration to be fetched in run-time.

Related Issue(s)

Refers to #178
Part of #2120
Closes #2121
Closes #1328
Closes #1348
Closes #2511

Description of Changes

Note. All of env vars / configs fields are optional and falling back to relative on web and dev in other cases.

You can set --dart-define=ENV_NAME / --flavor or non:

Notes

• env types dev|preprod|prod|relative
• if env is not specified relative is used for web or dev otherwise

Relative env type.

This env is ment to be used when building app for deployment. Doing it this way allows us to have single build which can be deployed anywhere together with gateway and get config this way.

Using dart-define

Use this method if you want to point always to main.dart and just change dart-define. Useful when building an app using cli tools or from IDE

flutter run --target apps/voices/lib/configs/main.dart --dart-define=ENV_NAME=prod

Using flavor

Works the same as dart-define just lower priority.

Using entry point

Probably preferred way in development setting. If you point to main_prod.dart|main_preprod.dart|main_dev.dart|
it will just use appropriate env and ignore any --flavour / --dart-define vars

flutter run --target apps/voices/lib/configs/main_prod.dart

Using main_qa.dart or main.dart will attempt to find env --dart-define or --flavor

Using bootstrap()

If you're starting app in tests you can override all of above using optional environment param.

Future<BootstrapArgs> bootstrap({
  GoRouter? router,
  AppEnvironment? environment,
})

Env source priority

1.bootstrap() overrides everything
2. "Entry Point" -> main_prod.dart|main_dev.dart etc
4. --dart-define -> ENV_NAME
5. --flavor
6. Fallback to relative on web and dev in other cases

Please confirm the following checks

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream module

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 744/748}$ | ${\color{red}Fail: 0/748}$ |

[dtscalac]

LGTM