Avoid custom INI file format in management framework

[awelzel]

We should consider to not use Python specific extensions (value-less entries) for the configuration files used in the management framework to aid consuming these files from different languages/bindings.

---

Just wondering whether I am reading the Wikipedia article on the INI format correctly, INI does not usually have value-less entries, right? I am asking since if that's correct, maybe we should fix our format to e.g., make it easier to use libraries to generate such files (coming my experience of trying to read the non-standard multi-line strings in zkg.meta files).

Regardless, the file definitely isn't TOML (e.g., strings are not quoted).

Originally posted by @bbannier in zeek/zeek-docs#228 (comment)

[ckreibich]

For some perspective: it is not at all clear whether zeek-client will even keep using the ini-ish config file format. Depending on where its functionality goes, something more structured like YAML could well happen.

In the case at hand the [instances] section that started the whole discussion is definitely preliminary. I just put something in there to get the difference between agent-to-controller and controller-to-agent connection initiation off the ground.

So read this ticket as "let's revisit in due course what's the right format for the config file", not whether what's currently there is more INI- or TOML-like.

[bbannier]

Thanks for chiming in here with some context @ckreibich. I asked Arne to file this ticket since my impression was that config format for the management framework was a "stable" API (introduced in zeek-5.0 so definitely something which would need planned deprecation paths there); the intention was to capture what could be relevant for such a discussion.

The need to be very careful about the highlighting in zeek/zeek-docs#228 definitely gave me pause as it can be an indicator of a weird API which not only could break highlighting (when rendered for the web or in editors), but could also make it harder than needed to generate and consume such files outside of our own special built tooling. We have such a story already with our multiline strings in zkg.meta which require handcrafted parsing logic, and I think we should avoid such APIs when not strictly needed.