Honor endpoint_type when requesting keystone for a token

The parameter 'endpoint_type' must be taken into account in case
one has different public and internal Heat endpoint

Change-Id: I63ffbec321e187f42405e1e70781065a274004d2
Fix shell operation with --os-auth-token

Currently the --os-auth-token/env[OS_AUTH_TOKEN] case doesn't
work, as we always expect a username/password to create the
connection to keystone.  This enables the client to be used
with only a token and tenant (which is required for keystoneclient
to retrieve the catalog) specified, e.g:

heat --os-auth-url http://127.0.0.1:35357/v2.0/ \
     --os-auth-token <a keystone token> \
     --os-tenant-id <tenant ID> stack-list

Change-Id: I478ce178f44e42c68153f1b347c6144f0a133f5b
Partial-Bug: #1252248
test_shell test current not deprecated options

Several tests are testing the old deprecated options, update to the
current equivalents

Change-Id: Ibc09ed44b72e07f94511a5dc4fc6c79a1ff6d400
Make tokens work with --os-no-client-auth

Currently --os-no-client-auth assumes you'll only ever want to pass
a username and password to the standalone auth_password middleware,
but it's also valid to pass a token and endpoint, which can then
be used to either connect to a normal (non-standalone) Heat without
needing the client to connect to keystone, or pass a token to custom
auth middleware in standalone mode where tokens are accepted.

e.g:

heat --os-no-client-auth
      --heat-url http://127.0.0.1:8004/v1/<tenant ID>
      --os-auth-token <a token> stack-list

Change-Id: Ie22c85ba5b3b987505f4d6204b4dd6ff03e0d912
Closes-Bug: #1252248
Merge "Fix shell operation with --os-auth-token"
Merge "test_shell test current not deprecated options"
Merge "Make tokens work with --os-no-client-auth"
Merge "Honor endpoint_type when requesting keystone for a token"