Backport of Auth method token_type possibleValues fix into release/1.13.x

[hc-github-team-secure-vault-core]

Backport

This PR is auto-generated from #19290 to be assessed for backporting due to the inclusion of the label backport/1.13.x.

The below text is copied from the body of the original PR.

---

When configuring an Auth mount the UI was displaying the following three types: default, batch and service. However, the API lists the following four possible types: default-service, default-batch, batch and service. This caused the following problems:

1. If the user didn't touch the Token Type dropdown we would send an empty string, which the api defaults to "default-service." However, if the user toggled this dropdown and then reselected default, and saved that value, the API returned with a not valid type error because it doesn't accept type default.

2. The UI displayed the wrong values. I suspect default in the UI was supposed to generalize default-batch and default-service, however, they mean different things and confused the user.

I have fixed these errors by setting noDefault=true on the dropdown and changing the possibleValues to match the API. Ideally the API's default value would be default-service because this is the value all current auth methods return when you send token_type=''. I went back and forth on whether I should make the default value "default-service" in the UI. However, I settled on following what the API behavior is just in case for some reason in the future another Auth method does not return default-service as the token_type when passing an empty string.

With the fix:

When they go to tune their mount it will show default-service because even if they didn't send a token_type the API returns default-service

I also went ahead and fixed an active class error on the section tabs in this area by removing a surrounding li element.
Before:

After:

Notes:

• the API doesn't list TokenType as a mount config option (it only shows that it's available for tuning). I'll make a ticket for this.
• The UI has fallen behind on some properties like allowed_response_headers and plugin_version that the API lists but we don't have in the UI (we show allowed_response_headers on secret engine mounts but not on auth methods even though it's in the mount-config model?). I'll follow up with this as well, but thought I'd add a note in case anyone has some background here.

---

Overview of commits

• 72bc820