Add host_routes property to Neutron subnet resource

Template snippet that was functionally tested:

subnet:
  Type: OS::Neutron::Subnet
  Properties:
    host_routes:
    - {destination: 192.168.1.0/24, nexthop: 192.168.1.2}
    network_id: {Ref: network}
    ip_version: 4
    cidr: 10.0.3.0/24
    allocation_pools:
    - {end: 10.0.3.150, start: 10.0.3.20}

(Next hop probably would make more sense to be in the CIDR)

Change-Id: I36f72f006a1ba48a6ed55a1c361b3df8d1359caa
Closes-Bug: #1250710
Add state check when suspend or resume stack

If suspend a stack which is already suspended,
some resource will throw exceptions.and you can't
suspend or resume that failed resource.

Add stack check when update or resume,if the
state of stack is expecter,return directly.

Change-Id: Ie6859c03168d9d18e88bbeb6df2c646541f2aa9d
Closes-Bug: 1284531
Provide attribute schema for waitcondition resource

Provide the waitcondition resource with an attribute schema defining
the Data attribute, so it will show up in the template guide docs.

Closes-Bug: #1280268

Change-Id: I8bcbd4b6795d4ca682ed933de437164675f66dc7
Fix some help strings in common/wsgi.py

Remove extra spaces, add missing closing brace, properly
capitalize strings.

Change-Id: I1464798c2d408d998b64a36c71b87a2956115d92
Remove signal_id from deployments API and model

The same information is now available from the deployment's
derived config deploy_signal_id input value.

Other deployment signal transports might not have a single ID
to put in this field so it is better at this stage to remove
it from the deployments model and do anything that is required
using derived config inputs.

partial blueprint hot-software-config

Change-Id: I90c85d0ceb9fd67eed640c84348ef4175a6194b6
Resource type implementation for software deployment

Some notes on the implementation:
  * Whenever a config should be deployed, this resource loads the config
    and creates an ephemeral derived config which has the following inputs
    added to it:
    * deploy_server_id
    * deploy_action
    * deploy_stack_id
    * deploy_resource_name
  * When signal_transport=CFN_SIGNAL, the folling input is added:
    * deploy_signal_id
  * When signal_transport=HEAT_SIGNAL, the folling inputs are added:
    * deploy_auth_url
    * deploy_username
    * deploy_password
    * deploy_project_id
    These inputs can be used by the hook *or* by the configuration script
    itself.
  * The ephemeral config also has the current input values inserted into
    the 'value' field of the config inputs. This allows the deployment
    metadata to be a simple list of configs.
  * Subclasses of SoftwareDeployment can make further transformations to
    the ephemeral config, such as transforming the config script to contain
    input values.
  * SoftwareDeployment is a SignalResponder so that it can receive
    output value updates from the server via curl or cfn-signal
  * By default, SoftwareDeployment remains in an IN_PROGRESS state
    until a signal is received
  * If wait_for_signal=False the resource will go immediately to COMPLETE
  * A deployment resource can be configured to deploy on any action.
    By default it deploys on CREATE and UPDATE
  * The outputs deploy_stderr, deploy_stdout and deploy_status_code
    are defined in the attributes schema, but other attributes map to
    whatever outputs are defined for the corresponding config resource
  * The resource will go into a FAILED state if an error_output output
    has a value, or if deploy_status_code is non-zero
  * If the 'name' property is set, this will set the 'name' property
    of the derived config, which will determine the sort order of configs
    returned when fetching a list of config metadata for a given server.
  * When an input_value is set where there is no corresponding config
    inputs schema entry, the derived config will add those input schemas
    to the derived input. This allows some templates to be more DRY.

Implements: blueprint hot-software-config

Change-Id: I97df5651dc6f27ed4ddc7355c21ab61270b15b68
Merge "Fix some help strings in common/wsgi.py"
Account for stack_user_project_id in stack_get_by_name

stack_get compares the context tenant to the stack tenant
and the stack_user_project_id. stack_get_by_name only filters
by tenant, so identify_stack fails when looking up by stack name
and the stack_user_project_id is the context tenant (such as when
there is a cfn API describe resource call).

This change searches for tenant or stack_user_project_id for
stack_get_by_name and stack_get_by_name_and_owner_id. It also
extends the tests to ensure a stack is returned when
stack_user_project_id matches, and no stack is returned when
tenant doesn't match.

Closes-Bug: #1288523
Change-Id: I875e232a791c71a4ad55a0e4e5a1423ec3546119
Merge "Remove signal_id from deployments API and model"
Merge "Resource type implementation for software deployment"
Merge "Add host_routes property to Neutron subnet resource"
Merge "Provide attribute schema for waitcondition resource"
Merge "Account for stack_user_project_id in stack_get_by_name"
Merge "Add state check when suspend or resume stack"