Have multiple configs instead of editing source code

[Leonidas-from-XIV]

This PR changes the way Sandworm is reconfigured by moving from editing sourcecode as part of an GH workflow into using a config file.

Some notes about it:

• It uses TOML. No particular significance about the format. The OCaml implementation seems to be well-maintained and the format is reasonably accepted. Could have used INI files as well, but the OCaml implementation is less mature.
• This PR gives up on the "staging" branch setup. It is easier to have a single main branch and have test as an option to its execution. We need to rework how to test things in either case.
• The config options are taken from the workflow

[Alizter]

Looks ok to me. It might be worth re-asking: Do we really want to get rid of staging? Isn't the point to isolate from "prod"?

[Leonidas-from-XIV]

I think we should have a way to test this, but the way this is currently setup is a mess:

• The config is in the workflows where it gets modified based on some conditions. This is not great for auditing and understanding what happens where and how.
• Setting up staging is quite complicated as this requires to re-set the branch every time and do the testing. Its currently 268 commits behind main and only one person can ever test at once.
• The metadata.json is part of the repo, thus one needs to be careful about not accidentally committing the bundle to the wrong branch otherwise the server serves redirects to non-existing files.
• The metadata.json is also part of the Docker container, so it needs to be redeployed on every change

What I think would be better is to have two environments with completely separate metadata.json that are not part of the repo (since metadata.json is more like a database than source code), with the configuration in the repository. Thus e.g. the workflows can choose which environment to upload to and the web server would be reading their own separate metadata.json from somewhere to know what they need to serve.

This is however a definitely out of the scope of this PR (and possibly more work than building a better design from scratch). So I can try to make this work with the staging branch but I am unsure whether it's worth the added work. @shonfeder what do you think?

[shonfeder]

What I think would be better is to have two environments with completely separate metadata.json that are not part of the repo (since metadata.json is more like a database than source code

I don't see a problem with keeping "the database" in the source code for a project like this. It give us an easy way to rollback, and keeps the infra minimal. Could we address your concerns with a metadata-test.json file?

This is however a definitely out of the scope of this PR (and possibly more work than building a better design from scratch). So I can try to make this work with the staging branch but I am unsure whether it's worth the added work. @shonfeder what do you think?

IMO, it is important that we can test changes before merging them into the trunk. But that doesn't necessarily mean we need a fixed staging branch: rather a way of deploying a selected branch to the staging environment. Does this make sense?

[shonfeder]

LGTM! Thanks :)