Prevent config rendering on every process

[gememma]

Closes #2936

[meowjesty]

Just some small stuff.

So if we save the config to an env var, we don't get the templating breaking on get_env secondary calls? Since we only do it once, is that what this PR is solving?

[gememma]

So if we save the config to an env var, we don't get the templating breaking on get_env secondary calls? Since we only do it once, is that what this PR is solving?

@meowjesty That's correct - the config template variables get resolved when the config file is rendered by Tera, which previously happened on every process. This causes an issue when a process tries to, for example, call get_env() to render the config but the process doesnt have access to the same env as previous ones - doing the get_env() call only once will solve this :) plus I think this way is more sensible in terms of reducing pointless recalculation and having fewer sources of truth

[DmitryDodzin]

I would check mirrord container due to changes to MIRRORD_CONNECT_TCP_ENV in exec, it should work but I would double check

[DmitryDodzin]

Im a bit worried for container feature behaviour where we split up the env variables for sidecar and main container relying on MIRRORD_CONNECT_TCP_ENV as env value

[gememma]

shouldnt it get passed through by the config anyway? the only time the env var is accessed is when a new config is created so the value should already be in there, right? you're right, there are definitely issues with config calculation - i think the container command relies pretty heavily on the config being re-calculated a few times, so it may have to be done manually