feat: decouple ui container from backend

[carlosthe19916]

No description provided.

[ctron]

Using a different server than the existing backend (based on rust), will might lead to a lot of new tasks on the security process side of things. Which we should avoid IMO.

[carlosthe19916]

• We need to list exactly which are those security processes and be specific on how much impact it will have without assumptions.
• I am sure there are more things than just fixing vulnerabilities but the fact that RHTPA V1 UI was based on Rust didn't prevent us to deal with npm security issues/tasks like this one https://issues.redhat.com/browse/TC-1770 . As long as there are npm dependencies we will need to deal with the tasks/issues related to it. And we already have a UI that contains npm dependencies. I'd like to understand how many tasks we are saving or increasing using a container just for the UI, considering the UI is already written in Typescript.

The reason of decoupling this is:

• The Operator is being used to continuously execute e2e tests against the whole Trustify project. The e2e tests although slowly is/will grow and as long as the backend does not have an "up to date" version of the UI those tests will frequently fail.
• @jcrossley3 is trying to continuously deploy the latest status of the project somewhere in the cloud. As long as the backend does not update the latest version of the UI after each commit done in the UI, the deployed version will always be outdated. Decoupling the backend and ui will allow the deployments to have always the latest version of both ui and backend as both create their containers after each commit is done in their respective repositories. This removes the need of the backend's source code always needing to manually update the version of the UI to be used.

[ctron]

• We need to list exactly which are those security processes and be specific on how much impact it will have without assumptions.

I agree. That should be part of the effort in evaluating the architecture.

• I am sure there are more things than just fixing vulnerabilities […]

Correct.