feat: switch to ibiofoundry hostname

[bodom0015]

Problem

We would like to serve a copy of this page at clean.platform.ibiofoundry.illinois.edu

Approach

• wip: serve at ibiofoundry host, redirect others to ibiofoundry (see comments for next steps)

DO NOT MERGE until the DNS rule has been set up for *.platform.ibiofoundry.illinois.edu DNS rule has been created 👍

TODOs

• New OAuth2 proxy instance needed to manage the new domain *.platform.ibiofoundry.illinois.edu
• Add new domain to existing CORS rules throughout (maybe utilize wildcards more frequently in CORS rules)
• need to revisit CLEAN job success/failed emails, which may no longer contain the correct hostname
• New Keycloak realm?

Considerations

With this approach, the URL would always say clean.platform.ibiofoundry.illinois.edu

The following hosts will redirect to this new hostname:

• clean.platform.moleculemaker.org -> clean.platform.ibiofoundry.illinois.edu
• clean.frontend.mmli1.ncsa.illinois.edu -> clean.platform.ibiofoundry.illinois.edu

How to Test

1. Navigate to https://clean.platform.ibiofoundry.illinois.edu/configuration
   • You should see the familiar CLEAN app
2. Navigate to https://clean.platform.moleculemaker.org/configuration
   • You should see the same familiar CLEAN app
   • NOTE: this is a single container of clean-frontend running with 2 separate hostnames, and currently both hostnames should be allowed to be used
   • Also noting that this case should actually FAIL, but for some reason right now it is succeeding.. which leaves me with other questions 😅

[bodom0015]

Reminder to update these rules to work the same way for mmli2 🙏

[bodom0015]

Double-checked and this has been deployed to production for awhile 👍 will deploy this to mmli2 when we're ready

Also confirmed that the changes currently running on production are reflected in this PR

[bodom0015]

This pattern does not allow the user to log in thru our existing configured OAuth2 Proxy. This instance will need to point at the new OAuth2 Proxy server for ibiofoundry and then the user would be able to log in 🙏 that said, I think we would need to rethink this pattern for it to work properly with SSO. More investigation is needed on that front

Easy alternative: we could probably just deploy an additional CLEAN frontend? An extra frontend webserver replica wouldn't eat up a whole lot of resources, and we can point it at our same backend system for running the jobs themselves