Honor falsy config values, and configured OpenStack credentials over the environment

[nuwang]

Two fixes surfaced during review of galaxyproject/galaxy#23098 (thanks @mvdbeek), both in how a provider resolves its configuration.

A config value of False or 0 is now honored

_get_config_value tested if self.config.get(key), so every falsy value read as "not configured" and the default was returned instead. s3_validate_certs: False (and ec2_validate_certs) silently left certificate verification switched on — the opposite of what the caller asked for, with no error — and a 0 for any numeric option was quietly swapped for its default.

Only None and the empty string now count as unset. That is what an absent value looks like arriving from YAML, a blank environment variable or a blank ini option, and no option has a meaningful empty-string value; False and 0 reach the SDK as configured. The three sources keep their order (config dict, then a config attribute, then the [<provider>] ini section), and the semantics are stated in the docstring and the setup docs.

Behaviour change to be aware of: a value that used to be ignored for being falsy now takes effect. A misconfigured 0 — say multipart_max_concurrency: 0 — therefore errors where it used to be masked by the default, which I think is the right outcome.

Explicitly configured OpenStack credentials take precedence over OS_*

The provider filled in every credential field from the environment whenever the config didn't name it, and _keystone_session prefers password authentication when both a password and an application credential are present. So a provider configured with only an application credential, running in a process that carried OS_USERNAME/OS_PASSWORD, authenticated as that ambient identity rather than the credential it was given. In Galaxy that meant a user-defined store could act as the server.

The two credential sets are now resolved separately: the environment only completes the set the config names (a configured os_username with the password in OS_PASSWORD still works), and is consulted for both sets only when neither is configured — the existing behaviour for the env-only case. The precedence between two configured sets is unchanged.

Tests

• tests/test_cloud_helpers.py: False and 0 are returned as configured; None and '' fall back to the default.
• tests/test_openstack_credentials.py (new): configured app credential ignores ambient password creds and yields a v3.ApplicationCredential auth; configured password creds ignore ambient app credential; env-only still works; the environment completes a partially configured set and only that set. Offline: the Keystone version probe is patched and keystoneauth plugins are inert until used.

Docs: setup.rst now states the lookup order and unset semantics, lists os_application_credential_id/_secret in the OpenStack table (they were missing, and username/password were marked required), and notes the per-set environment rule. Changelog entry under 4.4.2 - unreleased.