Added reference to the Nova Flavor documentation.

Updated contrib documentation with reference to the nova flavour README file.
Fixed the reference to the Docker documentation.

Change-Id: I23e352b8ec44424611066c0f64051ad3586b8c91
Fix test for stack delete on same active engine

The test was not starting the EngineListener, thus the engine_id was
None, so the corresponding code execution path was not actually
exercised.

Change-Id: If48ba9d3deb54f8e9ea1ed1987f832ddbaed33fc
Add native WaitConditionHandle resource

Adds a native OS::HeatWaitConditionHandle resource, which works
in a similar way to the CFN compatible one, but with a few changes
to make it simpler to use:
- The data passed is validated less strictly, so we tolerate missing keys
  for any of the data (we just fill in default values)
- A signal passed with no data is assumed to mean success
- There are two convenience attributes which provide a string representing
  the necessary curl call to send the signal (to the native ReST API)

This allows a similarly simple signalling mechanism to the CFN compatible
Handle resource, but with no dependency on the ec2tokens keystone extension
or heat-api-cfn service.

Some usage examples here:
  - https://review.openstack.org/106424

blueprint: native-waitcondition
Change-Id: Ie9b5aeb13bfab5fba55c1a49d1572e0777864b29
Update test_signal to use stub_keystoneclient

Adds an argument to stub_keystoneclient such that it can be used to
clean up the stubbing in test_signal

Change-Id: I5b29b0b2dd764c735aa0da7ee8d40d867c8b4f2f
Allow plugins to specify signal event reason

Currently, we have logic in the Resource.signal base-class implementation
which works out the reason string based on knowledge of some of the
signal-handling resources.  This is invariably going to be fragile, and it
won't work at all with any out of tree or contrib plugins.

So instead, move towards a model where we accept an optional return value from
handle_signal, and use that as the reason string instead.  Since no resources
yet return a reason, maintain the old logic as a fallback path, until this
gets migrated into the appropriate resources.

Change-Id: I45fdf112e6cd050bb1f4111977f653ba6440df02
Partial-Bug: #1340894
Allow Resources to select paths from attributes

Previously when get_attr included a path to select from the attribute, the
selection was done by the get_attr intrinsic function. Starting with the
Juno version of HOT, move control of this to the resource plugin, so that
individual resources (particularly ResourceGroup) can handle it themselves.

Related-Bug: #1341048
Change-Id: Ic3dc94a99a19e28a4f775198ff6e960e2efb8256
Exceptions ResourceInError, ResourceUnknownStatus

Resources which go into an unknown or error state currently
raise an Error exception. There are cases where Error is too
generic to make decisions on, so 2 new exceptions have been
created:
* ResourceInError: raised when a resource goes to a status which
  is known to represent an error for that resource
* ResourceUnknownStatus: raised when a resource goes to a status
  which heat is not aware of. If ResourceUnknownStatus is ever raised
  then this is a heat bug, since this is a status which heat is not
  aware of.

Any resource which go into an in-progress state has been updated to
raise ResourceInError and ResourceUnknownStatus where appropriate.

Change-Id: Ied83b030d30b8c26d9f4a1e454c71cd30715b0ba
Fixed wait skipped after 1st step of task

The first step of a generator type task is executed by the start
method and subsequent steps are executed by run_to_completion.
The TaskRunner skips the wait between the first step and second
step.
Added the sleep between transition from first step to second step.
Updated corresponding unit tests.

Change-Id: Iff30073ea0c060c6e2c89d7d9df8d0d03e816455
Closes-Bug: #1218187
Correct example syntax and whitespace

Corrects some examples and remove trailing whitespace in
the Heat Resource Plug-in Development Guide
page (pluginguide.html)

Closes-Bug: 1350503

Change-Id: I34b142e950b9a4588b415d44274732d835cfd8f4
Client plugin exception handling methods

This change adds common methods which allow resources
to handle client exceptions without needing to directly
import the exception types.

The most common client resource exception handling is:
* Detecting if an exception is a 404
* Raising any exception which is not a 404
* Detecting if an exception is a 413 (over limit)
* Detecting if an exception was raised by a particular client
  library

Subsequent changes will move to using these methods.

Change-Id: Ib2bd55c31e66b562cfa8388beb450be6c06cc4fb
Fix rollback failure when updating stack

When building oldstack in rollback, self.env doesn't match self.t, then
the validating will fail, but oldstack is useless in rollback, so we don't
need to build it in rollback.

Change-Id: Iab17824d108d565126c1dd0338fefc9a5ee4f47b
Closes-Bug: #1308883
Merge "Allow Resources to select paths from attributes"
Merge "Fix rollback failure when updating stack"
Merge "Exceptions ResourceInError, ResourceUnknownStatus"
Merge "Added reference to the Nova Flavor documentation."
Merge "Fixed wait skipped after 1st step of task"
Merge "Add native WaitConditionHandle resource"
Merge "Update test_signal to use stub_keystoneclient"
Merge "Allow plugins to specify signal event reason"
Refactor UpdateReplace exception

Use six.text_type to format error message, so that we can avoid
possible failure in unittest when switching to oslo.i18n.

Change-Id: I6979a3298ff5c3dac734bd7ad5534853bab1a7d8