Document new 7.11 central config vars as Central/Dynamic Configuration

[astorm]

When 7.11 of the Elastic Stack is released, update the agent docs for the following config vars to mark them as "Dynamic" (i.e. available in central config). Also possibly label the configuration as dynamic in Kibana X.Y.

• transaction_ignore_urls feat: transaction_ignore_urls wildcard matching #1876
• log_level feat: add log_level central config support #1908
• sanitize_field_names [META 319] Align sanitize_field_names option + central config #1811

[trentm]

This landed in Kibana in elastic/kibana#84678
@astorm @bmorelli25 Does that mean we add the badge to the docs now? Or when 7.11 is in freeze or released?

[astorm]

@trentm I'll ultimately defer to @bmorelli25, but my thinking on this is we wait for for 7.11 to be officially released. My thinking around this is based on the following use case

1. User comes to docs site, sees that this is a dynamic/central config
2. User goes to the most recently released version of Kibana (7.10) to look for config
3. User doesn't see this in central config. User is sad.

[trentm]

I defer to Brandon as well. :)

My preference in reading tech docs is to have "New in version X.Y"-like prose next to things for when they are added. That allows:

1. A user of an older version of something to read current docs to see what is coming and to be able to tell if something they are reading doesn't apply. E.g. these let me know about things in Python 3.8 and 3.9 even if I'm not quite using that version yet: https://docs.python.org/3/library/zoneinfo.html#module-zoneinfo https://docs.python.org/3/library/sys.html#sys.__breakpointhook__

2. It also lets us the maintainers add the docs in the same commit as the functionality, which is nice.

That said, it isn't a biggie either way.

[bmorelli25]

Generally in current, we try to avoid adding references to stack features before that version of the stack releases. But for a lot of different reasons, that's not always possible. In the past, for small changes like this, I've kept a release checklist of doc updates that need to be made before a release. I'm happy to add this one to my list for 7.11.

My preference in reading tech docs is to have "New in version X.Y"-like prose next to things for when they are added

I agree that the "New in version X.Y" or "Added in: vx.x.x", like we currently have in the Node.js APM API reference, is useful -- especially because we only publish a new documentation branch per major.

It also lets us the maintainers add the docs in the same commit as the functionality, which is nice.

For larger, or more complex documentation additions, I agree that this is a great benefit. We have coming soon tags (that render nicely in the docs) that we can add to the documentation in these cases:
coming:[7.11.0,This feature will be available when version 7.11 of the Elastic Stack releases.]. You can read more about them here.

[trentm]

Brandon,

Thanks! A release checklist for this sounds fine to me. We have this ticket already on our 7.11 milestone. I'll morph this one to cover all the of config vars being added to central config.