feat: derive release level

[noahdietz]

Adds a heuristic for deriving release level of an API path for a library based on the channel in the API path and the version of the library so that we no longer need to manually set the release level in sdk.yaml. Also removes the release_levels that were identified as extraneous (i.e. they match the result of applying the heuristic).

Regenerating Rust with this change only updates the showcase testing library to be marked as preview, and doing the same for Go produces the following diffs, which all seem reasonable based on either their current released version being 0.x or the pkg being alpha or beta.

Keeps the ability to manually override as there are some edge cases in Go that we likely need to push towards 1.x and thus ga OR just drop the beta flag if the module is already 1.x (#5303).

Fixes #4860

[gemini-code-assist]

Code Review

This pull request refactors the release level determination logic by introducing a version-aware heuristic in internal/serviceconfig/api.go and updating the corresponding sdk.yaml configuration. The changes replace static release_level overrides with a dynamic calculation based on API path maturity and library version. A high-severity issue was identified regarding the Go generator's compatibility with the preview release level, suggesting that 0.x versions should map to beta instead of preview for Go.

[jskeet]

Drive-by comment, based on the Gemini comment: should we have an enum for this, and then a mapping from the enum to language-specific value, rather than sticking to strings?

[noahdietz]

should we have an enum for this, and then a mapping from the enum to language-specific value, rather than sticking to strings?

@jskeet do you mean some constants for these values e.g. type ReleaseLevel string const Preview ReleaseLevel = "preview" and const Stable ReleaseLevel = "stable" rather than using "magic strings"? Yeah I can do that. Would be cleaner too if i end up precalculating release level and passing it through the call stack - the type being ReleaseLevel is more self-describing.

Non-sequitur: I need to double check the sdk.yaml changes, I suspect there wasn't enough context to make an appropriate determination of if the value was correct or not, need to verify.

[jskeet]

should we have an enum for this, and then a mapping from the enum to language-specific value, rather than sticking to strings?

@jskeet do you mean some constants for these values e.g. type ReleaseLevel string const Preview ReleaseLevel = "preview" and const Stable ReleaseLevel = "stable" rather than using "magic strings"? Yeah I can do that. Would be cleaner too if i end up precalculating release level and passing it through the call stack - the type being ReleaseLevel is more self-describing.

I'd meant an actual non-string enum, which could then be mapped to string on a per language basis. Or maybe we could do the consts as you describe, and just have a separate "map of ReleaseLevel to string" for Go...

[noahdietz]

I'd meant an actual non-string enum, which could then be mapped to string on a per language basis. Or maybe we could do the consts as you describe, and just have a separate "map of ReleaseLevel to string" for Go...

@jskeet I think I see what you are saying, but I'd like to punt on it. I think the language based uniqueness goes away once we get go on the preview/stable keywords (#4834) and the code is cleaner as a result. That shouldn't be hard to do and should be something we do soon as part of Go stabilization.