chore: document NodeConfig parameters

[Jiloc]

Description

Add documentation for all NodeConfig paramters

Applicable issues

• first step of Document config.toml options automatically #5898

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[wileyj]

few minor nits, but overall this is a great start!

[obycode]

This looks good, I just had some minor comments.

I think these descriptive comments should also be added to the NodeConfigFile struct, since this would be the one that would be most important to extract into documentation for users. Maybe it is less important to document the default values on NodeConfig and more important to show that on NodeConfigFile, since it would be shown to users trying to understand the config file.

[obycode]

I think these descriptive comments should also be added to the NodeConfigFile struct, since this would be the one that would be most important to extract into documentation for users. Maybe it is less important to document the default values on NodeConfig and more important to show that on NodeConfigFile, since it would be shown to users trying to understand the config file.

Per discussion in the Nakamoto sync, let's leave the comments as-is for now, and in a separate issue, we will work on merging the two versions of the config structs.

[Jiloc]

I think these descriptive comments should also be added to the NodeConfigFile struct, since this would be the one that would be most important to extract into documentation for users. Maybe it is less important to document the default values on NodeConfig and more important to show that on NodeConfigFile, since it would be shown to users trying to understand the config file.

Per discussion in the Nakamoto sync, let's leave the comments as-is for now, and in a separate issue, we will work on merging the two versions of the config structs.

@obycode Unfortunately, I couldn't attend today's sync :( , but your first comment is interesting because I actually came to a similar conclusion about where the docs might best live. When I worked on ConnectionOptionsFile in PR #6062, I realized that documenting the *File struct directly made more sense for user-facing TOML documentation, especially since the internal ConnectionOptions struct had tens fields not exposed in the config file that didn't make any sense to document this way.

Given that, I'd be open to move the documentation to the *File structs now, I'm happy to make that change for this PR (and the other 2). It should be a quick refactor on my end. This would give us more user-focused docs in the short term.

Of course, I'm also perfectly fine sticking to the plan from the sync if that's preferred, and then we can address it all during the struct merge.

Either way, great idea merging the two struct versions in the long run. It'll definitely simplify things and make the config handling clearer. We'll just have to decine on a strategy for the internal-only fields, but that's for the future discussion.

[Jiloc]

I think these descriptive comments should also be added to the NodeConfigFile struct, since this would be the one that would be most important to extract into documentation for users. Maybe it is less important to document the default values on NodeConfig and more important to show that on NodeConfigFile, since it would be shown to users trying to understand the config file.

Per discussion in the Nakamoto sync, let's leave the comments as-is for now, and in a separate issue, we will work on merging the two versions of the config structs.

@obycode Unfortunately, I couldn't attend today's sync :( , but your first comment is interesting because I actually came to a similar conclusion about where the docs might best live. When I worked on ConnectionOptionsFile in PR #6062, I realized that documenting the *File struct directly made more sense for user-facing TOML documentation, especially since the internal ConnectionOptions struct had tens fields not exposed in the config file that didn't make any sense to document this way.

Given that, I'd be open to move the documentation to the *File structs now, I'm happy to make that change for this PR (and the other 2). It should be a quick refactor on my end. This would give us more user-focused docs in the short term.

Of course, I'm also perfectly fine sticking to the plan from the sync if that's preferred, and then we can address it all during the struct merge.

Either way, great idea merging the two struct versions in the long run. It'll definitely simplify things and make the config handling clearer. We'll just have to decine on a strategy for the internal-only fields, but that's for the future discussion.

As per discussion in today's Naka sync, we'll keep the comments in the "non-file" structs, because the comments will be useful for the developers. We'll try to achieve the merging of the Config structs in the near future.

[fdefelici]

lgmt!