#197: Externalize config creation

[deveth0]

Hi again,

i spend some time on the weekend to find a better way to centralize the generation of the config files.

Currently both scenario.sh and docker-entrypoint.sh do very similar stuff but the scenario.sh is outdated and misses some of the improvements done in docker-entrypoint.sh.
To prevent this situation, I'd suggest to externalize the creation of the config/saves/mods folders into a script and call this from the entrypoints. So any update only needs to be done once and not in every entrypoint.

The same is valid for the start of the server, which in both cases requires the same parameters (aside from start-server-*** which is different. Currently the scenario.sh does not fall back to the factorio user but still executes factorio as root. Therefor I'd also suggest to use a central script here which can be called and takes care of the execution.

Please have a look into the code and give feedback.

Note: I also added an optional /provisioning folder, where any configs, saves or mods can be places. Those will be loaded when the server starts. This allows us to bootstrap the server without the need of any restarts (which is very handy when running e.g. on AWS or GCP where you don't want to access the container).

[janhartigan]

I like the idea of externalizing the config. Cleans things up a bit.

Could you explain a bit further how provisioning differs from mounting a volume using -v /opt/factorio:/factorio. Might be worth describing why it's useful in more detail in the readme as well. Thanks!

[bplein]

I worked on the original scenario code and I'm happy to have it replaced with an improved version. I'm not going to try and maintain it myself.

I use scenario2map (which runs and exits) and then relaunch my container with the same code I always use when restarting an existing server.

[SuperSandro2000]

Closes #223