Tests update FakeKeystoneClient to align user_id and trustor

When creating the dummy trust context, we return an arbitrary
hard-coded trustor_user_id, which makes testing we do things
with the trustor correctly difficult, so instead return the
user_id passed into the client (as this is what the trustor id
will be when real create_trust_context calls happen)

Change-Id: I280b820977bfc533126fe392e002210a996311f0
Cleanup trust on delete with stored context if needed

On delete, it's possible that someone other than the user who
created the stack may do the delete, e.g if there are a group
of heat users in a project who share responsibility for stacks.

Currently this causes an error if the user is not an admin,
because keystone default policy means only the trustor user (e.g
the user who originally delegated to heat via the trust on create)
or an admin may delete the trust.

So we check if the context user_id matches the user_creds trustor,
and if it doesn't we switch to the stored context to do the trust
cleanup so we avoid the delete failure.

I've avoided switching to the stored context unconditionally because
of the non-trivial overhead of creating a new keystoneclient object,
getting a new trust-scoped token etc.

Closes-Bug: #1308834
Change-Id: If408534ac7164e9d281dfbb6d4d39da97992f322
Don't delete stack domain project on stack-abandon

Currently we delete the stack domain project on abandon, which will
break any resources being abandoned that depend on users created in
the stack user domain.  So add a flag to skip deletion on abandon
and some tests to prove it works.

Change-Id: I883831a33d5bd326523836247683c161f797ee2a
Closes-Bug: #1300734
Merge "Tests update FakeKeystoneClient to align user_id and trustor"
Merge "Cleanup trust on delete with stored context if needed"
Merge "Don't delete stack domain project on stack-abandon"