Review `docset.yml` for subs that can be removed

[colleenmcginnis]

In my opinion, subs aren't as helpful if we don't use them consistently. In elastic/elastic-docs-vscode#2, we added inline warnings when an author hard-codes the value of a sub instead of using the sub key, which provides a light-touch way to encourage consistent use of subs and weed out unnecessary subs without introducing a bunch of errors.

However, there are some subs that are likely unnecessary, like api-examples-title: Examples, that should be removed from docset.yml. We should go through repo-level subs in this repo (and others) and eliminate any unnecessary subs.

cc @theletterf @florent-leborgne

[lcawl]

However, there are some subs that are likely unnecessary, like api-examples-title: Examples, that should be removed from docset.yml...

  api-query-parms-title:   "Query parameters"
  api-examples-title:   "Examples"

Those API substitutions were from when we were manually maintaining the API pages, so I agree we shouldn't have any need for them anymore.

I think any pages using these are likely out-dated too:

  monitoring:   "X-Pack monitoring"
  xpack:   "X-Pack"

[florent-leborgne]

IMO we should aim at keeping mainly:

• Product and solution names
• Branded terms that belong to Elastic and have strict usage rules like "Elastic AI Assistant", "Elastic Inference Service", though this last one isn't on that page yet. For ex, not sure we should have a sub for "Kubernetes".

And eliminate the rest unless there's an obvious benefit.

And make what's left consistent (include or exclude "Elastic" consistently, etc.")

Also, release notes shouldn't use subs. The goal for subs is consistent usage but also easy replacement once when needed. If something is called X in Kibana 7.5, it shouldn't be updated if it's suddenly called Z in Kibana 9.15