Bug 2053016

subscription-manager has two ways to get secrets from users in a non-interactively way:
- --password, for the password to use for an username
- --token, for authentication tokens

In case none is specified, sub-man will interactively ask for a password (for an username, which is the default). This approach has few downsides:
- since processes can be seen by anyone, passing an explicit --password or --token is not that secure on the same machine, as visible by other users
- passing things on stdin is possible, although not totally reliable (e.g. in case there are other interactive prompts, say sudo)
- they cannot be statically configured anywhere

The proposed approach is to combine them in a single new command line option with more flexibility: --secret SELECTOR. The format of SELECTOR is three-pieces separated by colon, i.e. "<type>:<source>:<value>"
- <type> describes what is the secret: "password", "token" are the values for the current options
- <source> describes what is the source of the secret:
  - "text" means that the the value represents the actual string of the secret, to emulate the current behaviour of --password and --token
  - "file" means that the value is a relative/absolute path to a text file which has a single line containing the secret
- <value> contains the actual value, and depends on "source"

This has few advantages:
- there is a unified way to specify secrets
- it is easier to add more secrets in the future without adding more command line options
- it is possible to put secrets in text files (whose permissions should be strict enough to avoid unneeded readers) without compromising them
- it is possible to retain the current behaviour of passing secrets inline as command line parameters
- --password and --token can become aliases for --secret password:text:<password> and --secret token:text:<token>
- it is possible to add more sources for secrets: a possible idea can be fd to specify a file description to read the secret from