Fix data_dir and config_file not reading systemd env vars

[kickster97]

WHAT is this pull request doing?

The config rewrite (#917) replaced the systemd-standard STATE_DIRECTORY and CONFIGURATION_DIRECTORY env vars with LAVINMQ_-prefixed variants. Since the systemd unit file (extras/lavinmq.service) declares StateDirectory=lavinmq and ConfigurationDirectory=lavinmq, systemd sets these vars automatically, and they are no longer read.

This means anyone using a non-default StateDirectory= path in a systemd override will have it silently ignored, falling back to the hardcoded /var/lib/lavinmq. Similarly, a custom ConfigurationDirectory= in a systemd override would be ignored when resolving the default config file path.

This PR restores both systemd env vars as fallbacks. LAVINMQ_DATADIR and LAVINMQ_CONFIGURATION_DIRECTORY still take precedence when set.

HOW can this pull request be tested?

run added spec

[claude]

PR Review

No issues found.

The changes correctly implement systemd environment variable support:

• STATE_DIRECTORY is read as a default for data_dir, with proper precedence: CLI > LAVINMQ_DATADIR env > ini > STATE_DIRECTORY > hardcoded default.
• CONFIGURATION_DIRECTORY is used as a fallback for config directory lookup, with LAVINMQ_CONFIGURATION_DIRECTORY taking precedence.
• Specs cover the new behavior and precedence rules.

[snichme]

The code looks to support multiple EnvOpt which means you could add
@[EnvOpt("STATE_DIRECTORY")] after the existing EnvOpt and it should pick one of them, the last should have precedence. Have you tested that?

[kickster97]

hm, yeah.. but the thing is that Crystals .annotation() (single) only returns the last annotation, so stacking @[EnvOpt] would silently drop all but the last env var. I'd need to change parse_env to use .annotations() (plural).

That works for data_dir, but config_file has to be resolved before parse_env runs because parse_ini needs the path first, so it still needs special handling. So I end up changing the macro, adding a transform lambda for the directory-to-filepath conversion, and still keeping the early lookup.

What do you think is the downside of the current solution?

[spuun]

I think it's a tiny change to the code to support multiple EnvOpt.

With the proposed solution in this PR, won't ini config values take precedence over these envs?

[kickster97]

With the proposed solution in this PR, won't ini config values take precedence over these envs?

ah yes thats true, need to fix that!

[claude]

PR Review: No issues found.

The changes are clean and well-tested. Precedence chains are correct, the multi-annotation macro change is sound, and the removal of the buggy EnvOpt on config_file (which would have set a file path to a directory value) is a good fix.