replace template_spec test with config_variables test

[khassel]

After introducing new config loading this PR replaces the obsolete template test with a config test.

[KristjanESPERANTO]

I'm not entirely sure, but I think the tests might not properly validate variable substitution? 🤔

The current tests check that logLevel and ipWhitelist equal the defaults, but the .env values are set such that they produce exactly those defaults after substitution:

• ["INFO", "LOG", "WARN", "ERROR"] = default
• ["127.0.0.1", "::ffff:127.0.0.1", "::1"] = default

These tests would pass even if substitution was broken. A test for timeFormat would be better since it's the only value that differs from the default:

it("config.timeFormat should be 12 from MM_TIME_FORMAT variable", async () => {
    expect(config.timeFormat).toBe(12); // default is 24
});

This should better verify that substitution works. WDYT?

[KristjanESPERANTO]

By the way: I just wanted to say that I'm really excited that we can now hide the secrets from the front end 😃

[khassel]

but I think the tests might not properly validate variable substitution?

they did. But I changed them now again so they are not testing against defaults.

If the variable substitution fails the bash variable remains in the config.

Examples:

	language: "${MM_LANGUAGE}",

So here the test will fail because "${MM_LANGUAGE}" not equals "de".

	timeFormat: ${MM_TIME_FORMAT},

Here loading the config would already fail when doing the config check.

[KristjanESPERANTO]

Nice solution 👍 🙂

[khassel]

the failed workflow concerning release creation is AFAIS related to github problems (next PR will pickup this too, so no problem):

[KristjanESPERANTO]

I have recently noticed problems with github workflow in various repositories. I haven't been able to identify a clear pattern yet. Perhaps Microsoft is making internal changes.

[khassel]

see https://www.githubstatus.com/