merge: Migrate to Quarkus-based web API

This pull request changes the web API to a Quarkus-based version. Currently, the OpenDC web API is written in Python (using Flask). Although Python is a powerful language to develop web services, having another language next to Kotlin/Java and JavaScript introduces some challenges.

For instance, the web API and UI lack integration with our Gradle-based build pipeline and require additional steps from the developer to start working with. Furthermore, deploying OpenDC requires having Python installed in addition to the JVM. 

By converting the web API into a Quarkus application, we can enjoy further integration with our Gradle-based build pipeline and simplify the development/deployment process of OpenDC, by requiring only the JVM and Node to work with OpenDC.

## Implementation Notes :hammer_and_pick:

* Move build dependencies into version catalog
* Design unified communication protocol
* Add Quarkus API implementation
* Add new web client implementation
* Update runner to use new web client
* Fix compatibility with React.js UI
* Remove Python build steps from CI pipeline
* Update Docker deployment for new web API
* Remove obsolete database configuration

## External Dependencies :four_leaf_clover:

* Quarkus

## Breaking API Changes :warning:

* The new web API only supports SQL-based databases for storing user-data, as opposed to MongoDB currently. We intend to use H2 for development and Postgres for production.

1 files changed, 9 insertions, 11 deletions

diff --git a/docs/architecture.md b/docs/architecture.md
index 7e644ec1..c4609ae9 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,23 +1,21 @@
 # Architecture
 
-OpenDC consists of four components: a Kotlin simulator, a MongoDB database, a Python
-Flask [API](/opendc-web/opendc-web-api), and a React.js [frontend](/opendc-web/opendc-web-ui).
+OpenDC consists of four components: a Kotlin simulator, a SQL database, a Quarkus-based
+[API](/opendc-web/opendc-web-api), and a React.js [frontend](/opendc-web/opendc-web-ui).
 
 ![OpenDC Component Diagram](./images/component-diagram.png)
 
 On the frontend, users can construct a topology by specifying a datacenter's rooms, racks and machines, and create
-scenarios to see how a workload trace runs on that topology. The frontend communicates with the web server over
-SocketIO, through a custom REST request/response layer. For example, the frontend might make a `GET` request
-to `/api/v1/users/{userId}`, but this request is completed via SocketIO, not plain HTTP requests. Note that the API
-itself can also be accessed by HTTP.
+scenarios to see how a workload trace runs on that topology. The frontend communicates with the web server via a REST
+API over HTTP.
 
 The (Swagger/OpenAPI compliant) API spec specifies what requests the frontend can make to the web server. To view this
 specification, go to the [Swagger Editor](https://editor.swagger.io/) and paste in
-our [opendc-api-spec.yml](../opendc-api-spec.yml).
+our [API spec](https://api.opendc.org/q/openapi).
 
 The web server receives API requests and processes them in the database. When the frontend requests to run a new
-scenario, the web server adds it to the `scenarios` collection in the database and sets its `state` as `QUEUED`.
+scenario, the web server adds it to the `scenarios` collection in the database and sets its `state` as `PENDING`.
 
-The simulator monitors the database for `QUEUED` scenarios, and simulates them as they are submitted. The results of the
-simulations are processed and aggregated in memory. Afterwards, the aggregated summary is written to the database, which
-the frontend can then again retrieve via the web server.
+The simulator monitors the database for `PENDING` scenarios, and simulates them as they are submitted. The results of 
+the simulations are processed and aggregated in memory. Afterwards, the aggregated summary is written to the database, 
+which the frontend can then again retrieve via the web server.