remotecfg: better handling of initial failures

[tpaschalis]

What's wrong?

If an Alloy local configuration cannot be loaded on startup, then execution will be aborted. After a successful initial load, subsequent reloads can be partially successful.

The same holds true today for remotecfg today, which (given no fallback cache file) requires all remote configuration to be loaded properly at least once before subsequent calls can partially update the graph.

Given the nature of remotecfg which can help people manage multiple configurations from a third-party place, this is potentially an unwanted behavior, as any errors in a child module cascades to break all pipelines. This means that Alloy cannot even send its own self-monitoring telemetry, making debuging difficult.

We should explore whether there's ways to relax this behavior for remotecfg and whether there's any drawbacks to doing so.

Steps to reproduce

Run remotecfg with two modules, one correct and one incorrect.

Notice that while one is reported as "Unhealthy", the other's status is "Unknown" and is not properly evaluated/started.

System information

No response

Software version

No response

Configuration

Logs