Check token validity when loading registry config

[kornelski]

This change checks validity of registry tokens earlier, when they're read from the config. Previously Cargo would check the token only when sending a request.

This makes the error message more helpful, because it can tell how the token has been defined. This is especially helpful when users do something like:

export CARGO_REGISTRIES_FOO_TOKEN=$(misconfigured tool printing error messages)

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

This is moving the check from

• token credential provider

To

• token credential provider
• paseto credential provider
• the enumeration of all credential providers

I'd want to better understand if its a good idea to be running this check in all of those other situations

CC @arlosi

[kornelski]

Construction of RegistryConfig is closer to TOML deserialization of credentials.toml than to implementation of credential providers. The token here is the input for downstream users of the registry config, and does not touch output token of credential providers (that's CredentialResponse).

Paseto uses secret_key and secret_key_subject fields, not token.

This field is only read by TokenCredential, apart from code that warns when cargo::token is not enabled.

[kornelski]

I've found another case where extra \n in the token causes an internal error:

Caused by:
  download of config.json failed

Caused by:
  failed to download from `[…]/index/config.json`

Caused by:
  [43] A libcurl function was given a bad argument

Fixed in e70f340 (the tests and released builds of Cargo report this error slightly differently, presumably because the tests use a custom mock HTTP server).