Accept on/off values for --use-keyring

[rolandwalker]

Description

Accept on/off values for --use-keyring, keeping true/false, as well as treating "reset" as special.

The motivation is uniformity in the interface.

The only loss is that click does not display the value choices in the helpdoc, but they are already listed in the description.

Here we also change the description to suggest on/off, while continuing to silently accept true/false. The reason for the change is that --ssl-mode came first, and --ssl-mode takes on/off.

See #1606 for more on the motivation.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[github-actions]

Findings

1. Regression: invalid --use-keyring values now raise an uncaught ValueError (likely traceback) instead of a clean CLI validation error.
   The option was changed from click.Choice to str, and parsing now happens in str_to_bool. Any unexpected value (e.g., --use-keyring maybe) will bubble up from str_to_bool without Click’s usual usage/error formatting. Consider using click.Choice([...], case_sensitive=False) with a custom callback for reset, or catch ValueError and raise click.BadParameter for consistent UX.
   Ref: mycli/main.py:1725, mycli/main.py:2066

Missing tests / edge cases

1. No coverage for invalid values (e.g., --use-keyring maybe) to ensure a friendly error and exit code.
   Ref: test/test_main.py
2. No coverage for --use-keyring reset (or case variants) to confirm it still forces use_keyring=True and reset_keyring=True.
   Ref: test/test_main.py

If you want, I can suggest a small patch to keep the on/off acceptance while preserving Click’s validation behavior.

[scottnemes]

Similar comment to the ssl_mode one, the naming of --use-keyring actually makes sense for true/false, but doesn't really make sense for on/off. If anything this is more about option naming vs values.

I think setting clear expectations in the command/option is the most important anyway, so if it's true/false, then the option should be bool, and that is clear to the user. If it's not true/false, and has a set of values like ssl_mode (on/off/auto), then choice is preferred to enforce that.