chore: provide a tool for generating config docs

[neverchanje]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

To provide an automation tool that can help generate an up-to-date document for configurations.
This tool does not require a separate command. Instead, it reuses ./risedev generate-example-config.
The result can be copied without modification into our official doc upon every version release.

A follow-up task is to refine the rustdoc for important configurations, which are supposed to be maintained by developers instead of the doc team.

In addition, we may need to figure out an approach to extract the possible options for each config. We currently can only extract default values. For example, there is no annoation to indicates default_parallelism's other options except for 'full',

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

https://github.com/risingwavelabs/risingwave-docs/issues/997

[github-actions]

license-eye has totally checked 4760 files.

Valid	Invalid	Ignored	Fixed
2073	1	2686	0

Click to see the invalid file list

• src/common/proc_macro/src/config_doc.rs

[BugenZhao]

Generally LGTM.

• Shall we apply the same ordering as example.toml?
• Should we include the developer configs?

[neverchanje]

I am not sure what ordering does example.toml use. But it'll be fine if they aren't consistent.

Should we include the developer configs?

The thing is, 'developer' configs somehow have prefixes like 'streaming_' or 'batch_' that make the toml configs unaligned with the rustdoc.

When the tool extracts rustdoc (comments), it's unware that a field xxx in streaming developer configs will be prefixed as "streaming_xxx", which cannot be found within the config table generated by ConfigDoc macro.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
9425213	Triggered	Generic Password	d4804d2	ci/scripts/regress-test.sh	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[xxchan]

LGTM.