[Request] Generate config settings docs

[kilfoyle]

Our first YAML-sourced config settings file is now fully ready to render into the docs output.

I've:

• Converted all descriptions, admonitions, and examples to Markdown format.
• Added applies_to properties with the versioning details (Note that these aren't exhaustive: I'm basically saying "supported on self-hosted and cloud" versus "supported on self-hosted only", since that's all I know for any given setting, and that's all that we currently have documented.).

This early Automated settings reference prototype looks very nice. I think what we still need is:

• Split the setting descriptions into multiple paragraphs.
• Call out the datatype, and any default or options on separate lines.
• Make sure that code examples are rendering.

---

xpack.actions.ssl.proxyVerificationMode

Controls the verification for the proxy server certificate that Kibana receives when making an outbound SSL/TLS connection to the proxy server.

Use full to perform hostname verification, certificate to skip hostname verification, and none to skip verification.

Equivalent Kibana setting

Datatype: enum
Default: full
Options:

• full
• certificate
• none

---

[lcawl]

In case it affects this issue, I've done some cleanup and consolidation of the manually-maintained copy of this settings file in elastic/kibana#214934, so we'd want to make sure any changes there are reflected in the yaml too before replacing the markdown file.

[kilfoyle]

@lcawl Thanks for the heads up. I can redo the yaml version of the Alert and Action settings file. Can you please tag me on the issue or PR for "Part 2" of the cleanup work when it happens? I might as well wait until that's complete just to avoid porting the changes over twice.

[lcawl]

Another passing note based on a slack thread where folks were asking how/if version-specific changes to the behaviour of settings would be called out. My assumption is that when there are significant changes to the behaviour in a setting (e.g. the index.codec setting was given as an example of one that changed between 8.14 and 8.17), they would be covered in prose in the description. Ideally when this rolls out we'll give some concrete examples of how to do that well.

It also makes me think the applies_to in these setting files should support all the same values as https://docs-v3-preview.elastic.dev/elastic/docs-builder/tree/main/syntax/applies#sections (i.e. so that we can indicate when a setting was added, removed, etc and what its lifecycle state is). If that occurs I think the state: deprecated/hidden/tech-preview field becomes redundant. If there's a more appropriate meta-issue to use for these future musings, lmk!

[lcawl]

Until the output can be generated automatically in markdown format (or read directly in yaml format), I've been manually copying changes into markdown format. For example, in elastic/kibana#220058