Solution to provide Angular app deployment flexibility

Routing information is being placed in at develop time in the Angular api service files. This makes deployment involve app code changes. Here are the hardcoded values:

https://github.com/bcgov/mem-admin/blob/d105e7177507b7e2916af08841951ab96e737b8d/modules/utils/client/services/utils.client.services.js#L80

**Background**

This has been a challenge to address up to now in API backed Angular front-ends ([architecture diagram](https://github.com/bcgov/eagle-dev-guides/blob/master/dev_guides/architecture.md)) that are built using the s2i built approach ([build diagram](https://github.com/bcgov/eagle-dev-guides/blob/master/dev_guides/s2i_extended_builds.md)), which creates a high performance web server image but at the cost of extra build complexity.

**Solution**

Here is a simple pattern from Eagle EPIC that solves this in a few lines, meeting the https://12factor.net Factor III, "Store config in the environment" and allowing the app to be deployed based on settings alone. It handles the more complicated s2i builds (other projects that expose environment settings in a similar pattern like MDS use a much [simpler build process](https://github.com/bcgov/mds/blob/develop/openshift/_nodejs.bc.json)).

Please see the following areas of code:

1. [Here's where the Angular app consumes the settings from the server and replaces the hardcoded routes](https://github.com/bcgov/eagle-public/blob/53b42222280aaad9972525ecdffd4ad4ff4b73e4/src/app/services/api.ts#L41)
1. [Make sure this line gets placed in the HTML head as it needs to run prior to app load](https://github.com/bcgov/eagle-public/blob/1c51106bb7f94495391c9a0f322f06fd533d792e/src/index.html#L61)
1. [Create the landing point for the environment variables at server build time](https://github.com/bcgov/eagle-public/blob/53b42222280aaad9972525ecdffd4ad4ff4b73e4/openshift/templates/nginx-runtime/Dockerfile#L7)
1. [When the pod starts up, and on every subsequent redeployment, set the variables](https://github.com/bcgov/eagle-public/blob/53b42222280aaad9972525ecdffd4ad4ff4b73e4/openshift/templates/nginx-runtime/s2i/bin/run#L5). Javascript was chosen over JSON as it's a direct plugin for the existing variables in api.ts without having to do overhead to handle the JSON. [MDS uses JSON](https://minesdigitalservices.gov.bc.ca/env).
1. [Pass the environment variables along](https://github.com/bcgov/eagle-public/blob/53b42222280aaad9972525ecdffd4ad4ff4b73e4/openshift/templates/angular-on-nginx/angular-on-nginx-deploy.json#L75)
1. [Settings exposed in OpenShift](https://github.com/bcgov/eagle-public/blob/53b42222280aaad9972525ecdffd4ad4ff4b73e4/openshift/templates/angular-on-nginx/angular-on-nginx-deploy.json#L252)

You can check if your settings are exposed by (if you used the same pattern as above) visiting https://your-front-end-url/publicServerEnvironmentSettings.js

And remember to set your app to redeploy on environment variable change. That way your app will get new environment settings without needing a build.

Cheers!

PS. If you have a discrete admin site, the above solution uses the same pattern with slight variations on the path (/admin in the [server build](https://github.com/bcgov/eagle-admin/blob/d18f246f93a3b024604ea004a5193634cb865a12/openshift/templates/nginx-runtime/Dockerfile#L8) and image [startup script](https://github.com/bcgov/eagle-admin/blob/d18f246f93a3b024604ea004a5193634cb865a12/openshift/templates/nginx-runtime/s2i/bin/run#L5) but [html stays the same](https://github.com/bcgov/eagle-admin/blob/d18f246f93a3b024604ea004a5193634cb865a12/src/index.html#L46)). Note the use of uniquely named client-side variables to avoid collisions ([public](https://github.com/bcgov/eagle-public/blob/develop/src/app/services/api.ts#L41) vs [admin](https://github.com/bcgov/eagle-admin/blob/develop/src/app/services/api.ts#L62)).

Start with modules/utils/client/services/utils.client.services.js around line 80 to identify the hardcoded routes, then compare the referenced Eagle app files for runtime settings, the HTML entry point, the nginx Dockerfile, startup script, and deployment template. Done means deployment settings can change through environment variables without changing or rebuilding application code, with redeployment applying updated values.

Written by the indexing model from the issue text.