[Task] Safe Mode - filesystem based config file improvements

[Gnuxie]

Main story: #1

Description

Some support requests are a result of misconfiguration in the config file. When we get these requests, it's sometimes completely unclear where the config file is being loaded from (due to the behavior of the config npm package (the-draupnir-project/Draupnir#218).

Acceptance Criteria

• When draupnir starts, the path used to load the config file is shown.
• When draupnir starts, any non-default configuration values are pretty printed to the log (with secrets redacted).
  * This was too noisy, so instead we will print them only on exit.
• It is clear where secrets came from, for example if systemd load credentials is used, then it is obvious the access token is being provided from an argument rather than the config file.
• If draupnir is started with anything other than --draupnir-config, then a warning is shown that their method of providing the config is deprecated.
• There is backwards compatibility with --mjolnir-config.
• All the information shown at startup is also shown on exit, because Draupnir will have been running for a long time before it crashes etc.

Stretch

• Configuration values that are known to be the same as the defaults are omitted and shown separately.
• When unknown configuration values are found, warnings are shown in order to prevent typos.

Issues

• It should be easier for system admins to debug startup failures as a result of a misplaced config file or incorrect config values. Draupnir#217
• Starting Draupnir with --draupnir-config incorrectly warns that he config can't be found because of theConfig package behaviour  Draupnir#480
• Draupnir should scream if it is started without the explicit --draupnir-config argument, because the legacy modes of starting Draupnir without config are fragile. Draupnir#218

PRs

• Filesystem config improvements Draupnir#604
• Suppress 'config' package's warnings when config file is missing. Draupnir#606

[Gnuxie]

Ok, so the way I'm thinking of doing this is

1. At startup keep a clone of the original config somewhere, and print that. This should also be accessible via a command in either normal or safe mode (or just the config logging part, doesn't have to be the clone specifically).
2. Ideally we'd have access to some utility from a library or otherwise that would be able to detect values that are equal to the default and strip them out, so the first step can be skipped.

For arguments such as --draupnir-config and systemd load credential paths, we can probably just introspect directly on the arguments to see if they're there. I wonder if we could reuse @the-draupnir-project/interface-manager to extract them as keyword arguments. Might be too fragile though, might be able to just reuse the ParsedKeywords object and do the parsing manually and not tell anyone.

---

So it turns out https://github.com/node-config/node-config/wiki/Using-Config-Utilities#diffdeepobject1-object2-depth can be used. The documentation says that it works best if we clone the default first, apply the config over it and then make the diff.

[Gnuxie]

Do we need to show the config at start? if the bot crashes at startup the config will get printed anyways. So why don't we just leave it to be printed on exit?

Well, part of the problem is when should we setup the exit hook?

[Gnuxie]

Tue, 08 Oct 2024 11:28:13 GMT [INFO] [Draupnir config] Configuration meta: {
  "configPath": "/home/user/experiments/Draupnir/config/harness.yaml",
  "isDraupnirConfigOptionUsed": false,
  "isAccessTokenPathOptionUsed": false,
  "isPasswordPathOptionUsed": false
}
Tue, 08 Oct 2024 11:28:13 GMT [WARN] [Draupnir config] DEPRECATED Starting Draupnir without the --draupnir-config option is deprecated. Please provide Draupnir's configuration explicitly with --draupnir-config. config path used: /home/user/experiments/Draupnir/config/harness.yaml