Openapi: adding more info in x-state, adding x-state info to fields and params

[l-trotta]

Closes #4386, Closes #4356.
Couple of doubts:

• This would replace "x-beta" with "x-state" in the Beta case, and change the field type from a boolean to a string, is this okay?
• Does this also have to be configurable, or can it be the standard output?

[lcawl]

• This would replace "x-beta" with "x-state" in the Beta case, and change the field type from a boolean to a string, is this okay?

There is info about the differences between these extensions in https://docs.bump.sh/help/specification-support/doc-badges/. The benefit of using x-beta was that it affected what was deemed a "breaking change" in the automated changelog. However, given that we didn't have the same consideration for tech preview / experimental states, IMO it's not worth trying to have both the x-beta and x-state applied. Rather, I think the latter is the richer and more consistent option.

• Does this also have to be configurable, or can it be the standard output?

Since this PR affects only a specification extension, in my opinion it should be something that's ignorable by any other tools or processes that consume these OpenAPI documents. That is to say, IMO it can be standard output.

[lcawl]

I did a quick skim of the output and the elasticsearch-openapi.json changes LGTM. The elasticsearch-serverless-openai.json, however, seem to inherit some of the non-serverless details. If this ought to be tracked in a separate issue, lmk, but here's what's in the specification, for example:

 * @rest_spec_name async_search.delete
 * @availability stack since=7.7.0 stability=stable
 * @availability serverless stability=stable visibility=public

And here's what I see in this PR's serverless-specific output:

 "summary": "Delete an async search",
 ...
 WAS:       "x-state": "Added in 7.7.0"
 NOW:       "x-state": "Generally available; Added in 7.7.0"

IMO the output should match the @availability serverless definition and just say "Generally available".

[l-trotta]

@lcawl fixed the serverless output!
@swallez right now what happens if there's no flavor set in the configuration is that availability gets completely skipped, because if it does both stack end serverless we'll have the same bug as before where the first info gets overwritten. Should we have "stack" as default flavor if none is set?

[l-trotta]

@lcawl @swallez ready for review!

[lcawl]

Output LGTM, thanks!

[swallez]

Left a some code style comments. format!() is your friend for string formatting and even concatenation!

[swallez]

The config is part of tac, I added it in #4313. This effectively makes TypesAndComponents more than types and components. I'll open a PR to rename it to something more "kitchensink-esque" like Context.

[swallez]

The + operator on String is rarely used in Rust. Prefer the more compact and more efficient since_str = format!("; Added in {since}");

[github-actions]

The backport to 9.0 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-9.0 9.0
# Navigate to the new working tree
cd .worktrees/backport-9.0
# Create a new branch
git switch --create backport-4431-to-9.0
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6998d91c470b460f0cd6928bedb71027fa26696f
# Push it to GitHub
git push --set-upstream origin backport-4431-to-9.0
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-9.0

Then, create a pull request where the base branch is 9.0 and the compare/head branch is backport-4431-to-9.0.

[github-actions]

The backport to 8.18 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.18 8.18
# Navigate to the new working tree
cd .worktrees/backport-8.18
# Create a new branch
git switch --create backport-4431-to-8.18
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6998d91c470b460f0cd6928bedb71027fa26696f
# Push it to GitHub
git push --set-upstream origin backport-4431-to-8.18
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.18

Then, create a pull request where the base branch is 8.18 and the compare/head branch is backport-4431-to-8.18.

[github-actions]

The backport to 8.19 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.19 8.19
# Navigate to the new working tree
cd .worktrees/backport-8.19
# Create a new branch
git switch --create backport-4431-to-8.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 6998d91c470b460f0cd6928bedb71027fa26696f
# Push it to GitHub
git push --set-upstream origin backport-4431-to-8.19
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.19

Then, create a pull request where the base branch is 8.19 and the compare/head branch is backport-4431-to-8.19.

[lcawl]

💚 All backports created successfully

Status	Branch	Result
✅	9.0

Questions ?

Please refer to the Backport tool documentation

[lcawl]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Questions ?

Please refer to the Backport tool documentation

[lcawl]

💚 All backports created successfully

Status	Branch	Result
✅	8.18

Questions ?

Please refer to the Backport tool documentation