conf: support optional include? directive

[olliehcrook]

Add parsing support for include? <path> so missing include files are ignored.

Keep existing behavior for invalid include files and add lexer/parser tests.

Implements: #5297

Signed-off-by: Ollie Hensman-Crook olliehensmancrook@gmail.com

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 09a557f530

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[neilalexander]

I'm trying to understand in what situation this would be useful. If an include is missing and we ignore it, then the system can and will come up in a possibly-unsupportable or unexpected state.

[wallyqs]

@neilalexander it is often requested as an alternative to create empty files or having to do it via external template systems, helps simplify that flow

[neilalexander]

@wallyqs I am concerned mostly about the supportability aspect.

What happens in a situation like when you lose or accidentally truncate/delete/mangle an included file with the JetStream store_dir setting in it and it silently comes up with a temporary directory instead?

These kinds of hidden behaviours always end up being surprising at the worst times, usually during an incident, when you find out that the server isn't doing what you thought it was and it didn't fail-fast when it should have done.

[wallyqs]

@neilalexander the same thing could happen right now if using include and the included file becomes empty, this only skips when file is missing so parsing and other i/o errors aren't ignored either. One thing to detect the change too is to use the config digest to track whether the behavior of the past boot is different from the current boot, the presence of the include? would show it to be different.

[wallyqs]

I like the idea though of making it super explicit in terms of behavior in the config to have better protection, something like:

$ echo 'jetstream {
  store_dir = "./here"
}' > foo.conf

$ nats-server -c foo.conf -t
nats-server: configuration file foo.conf is valid (sha256:2e882ecf83c5d9ef4c4501f0f5bbe47ca57dcbe847d924cd69f26ee123da93f1)

then use:

include? ./foo.conf "sha256:2e882ecf83c5d9ef4c4501f0f5bbe47ca57dcbe847d924cd69f26ee123da93f1"

[neilalexander]

@derekcollison Do you have any thoughts on this one?

[derekcollison]

@derekcollison Do you have any thoughts on this one?

I am ok with this. Since its an opt-in via include? and current behavior is not affected.