Alarm server: Allow multiple -settings

[kasemir]

Just like the phoebus GUI, it should allow multiple settings, like

alarm-server -settings /path/to/global/settings.ini -settings /path/to/more/specific/settings.ini

Fixes #3848

• Testing: Manual

Before this fix,

alarm-server -settings /path/to/global/settings.ini -settings /path/to/more/specific/settings.ini

would ignore the global settings. Now it loads global and then specific settings.

Before this fix

alarm-server -settings MISSING_FILE.ini -settings /path/to/existing/settings.ini

would not notice the missing file because it ignored all but the last settings.
Now it will load all provided settings in the listed order and notice the missing file.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kasemir]

The alarm server actually allowed multiple -settings until a9e6473c8b, and since we had an operational alarm server in place since 2022, we only noticed now that multiple -settings had been broken

[shroffk]

In this situation, each successive settings is of higher priority and would override any duplicate preferences from the previous settings file?

While not a fan of ordered arguments, I would think the global preferences are packaged with the site specific product and a single setting file would be enough to override the specific preferences based on deployment details.

However, since we have this feature could we consider a core settings utility service? It would be easier to have unit tests to prevent this for happening again.

[kasemir]

Feel free to re-package this, but we do rely on the end result of supporting multiple -settings.
SNS has one product, preconfigured for office use.
On the accelerator, that's used with -settings for_accelerator.ini.
On beamlines, it's used with -settings for_all_beamlines.ini -settings for_the_specific_beamline.

The alternative would be about 30 different products, which doesn't seem practical. After all, people tend to not build many site-specific copies of caget but use the one and set EPICS_CA_ADDR_LIST via a cascade of shell settings (/etc/profile.d, ~/.bashrc and so on).

[shroffk]

I understand the usecase

we did 2 products

xxx-phoebus-accl : this is packaged with for_accerator.ini

xxx-phoebus-beamline: this is packaged with for_all_beamlines, then run with -settings for_the_specifc_beamline

This was just an FYI, my main goal here would be add tests so that we don't accidentally break this in the future