EASI-4671: Refactor configuration to build frontend for k8s as static content

[Jdwoodson]

EASI-4671

Description

This pull request includes changes to the deployment and configuration of the EASI application in EKS, focusing on environment variable management, Dockerfile updates, and Kubernetes configuration adjustments.

Environment Variable Management:

• Added build arguments for environment variables in .github/workflows/deploy_to_eks.yml to avoid hard-coding sensitive data.
• Updated Dockerfile.frontend_k8s to accept environment variables as build arguments and set them as environment variables within the container.

Dockerfile Updates:

• Removed the Dockerfile.backend_k8s file, utilizing the same Dockerfile for the backend as is deployed via ECS.

Kubernetes Configuration Adjustments:

• Removed the easi-frontend-configmap.yaml file and references to it in deployment configurations, moving environment variable management to build-time arguments. [1] [2] [3] [4] [5]
• Changed frontend service and ingress configurations to use port 80 instead of 3000. [1] [2] [3]

Code Updates:

• Updated frontend code to dynamically determine API and GraphQL addresses based on the current window location, improving flexibility and reducing hard-coded values. [1] [2] [3] [4] [5] [6]
• Added a utility function getWindowAddress to retrieve the current browser's address.

These changes collectively enhance the application's deployment flexibility, security, and maintainability.

How to test this change

• Deploy an environment via EKS using the Deploy to EKS action and select the EASI-4671 branch.

PR Author Checklist

• I have provided a detailed description of the changes in this PR.
• I have provided clear instructions on how to test the changes in this PR.
• I have updated tests or written new tests as appropriate in this PR.

PR Reviewer Guidelines

• It's best to pull the branch locally and test it, rather than just looking at the code online!
• When approving a PR, provide a reason why you're approving it
  • e.g. "Approving because I tested it locally and all functionality works as expected"
  • e.g. "Approving because the change is simple and matches the Figma design"
• Don't be afraid to leave comments or ask questions, especially if you don't understand why something was done! (This is often a great time to suggest code comments or documentation updates)
• Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.