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
use correct url on Windows platform

os.path.normpath is used to clean url. On windows platform, it
returns url with "\" instead of "/", which is required in heat api
 in:
/heat/heat/api/middleware/version_negotiation.py,
path_info_peek method.

Change-Id: Ic1a5fc5dd789a7996e08a85a9d8908267e203565
Closes-Bug: 1254657
Pass only tenant name or ID to keystoneclient

When creating the keystoneclient, we only need to pass the tenant
ID or name, not both

Change-Id: I0dd03759979026daba1be343f7194f9b7e15a589
Cleanup exc.verbose after tests

A couple of tests override the (module level) exc.verbose flag,
but fail to reset it after the test, which leads to failures
if a test expecting non-verbose exception format happens after the
verbose test.

Change-Id: Iac633707e74464f8d6509a0c5aa0cc62da00ce47
Use fixtures for all shell environment variables

Currently only the variables related to the test are set, so
any other OS_* variables in the local environment can affect
the test results leading to confusing results.  Setting all
variables not passed into fake_env to None will delete them
in the fixture, hence ensuring a consistent test environment.

Change-Id: I24a07ef5fc89ca9fff121fe206b8e314f23c4402
Don't call credentials_headers() twice

We don't need to call credentials_headers in the stack create/update
code, as it's already called in the HTTPClient.  This has the side-
effect of simplifying the shell test, which currently has to mock
header arguments to json_request, which are incorrect anyway because
HTTPClient always sets X-Auth-Token if a token is passed in (as
evidenced by bug #1250731)

Change-Id: I6212cf5a50f5a8d919f743e23ece4bd1d0e1ad1c
Partial-Bug: #1252248
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 "use correct url on Windows platform"
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"