Pass instance to set_instance_error_state vs. uuid

Quick fix to patch one case in which instance.uuid was still being
passed to _set_instance_error_state when retries are disabled in
rescheduling cases.  Also updated the respective test case.

Change-Id: I24a682b926bc570d7e932ffedc664a95d41fda85
Closes-Bug: #1367342
Add quotas for Server Groups (V2 API compatibility & V2.1 support)

Server groups can be used to control the affinity and anti-affinity
scheduling policy for a group of servers (instances).  Whilst this is
a useful mechanism for users such scheduling decisions need to be
balanced by a deployers requirements to make effective use of the
available capacity.

This change adds quota values to constrain the number and size of
server groups a user can create.

Two new quota values are be introduced to limit the number of server
groups and the number of servers in a server group. These will follow
the existing pattern for quotas in that:

* They are defined by config values, which also include the default
  value

* They can be defined per project or per user within a project

* A value of -1 for either quota will be treated as unlimited

* Defaults can be set via the quota groups API

* Values may be changed at any time but will only take effect at the next
  server group or server create.   Reducing the quota will not affect any
  existing groups, but new servers will not be allowed into group
  that have become over quota.

This is part one of a linked sequences of changes that implement the
new quotas - split to make the reviews easier.

This part adds the definition of the new quota values, but leaves the
V2 API unchanged.  The V2.1 API is updated as it shows all quota values.

The second part adds the new V2 API extension to make the new quota
values visible and changeable.  At this point a Tempest change is
required to get a clean run as it checks for a specific set of
values.

The third part implements the quota checks themselves.

Thanks to Cyril Roelandt for supplying some of the unit tests.

Co-authored-by: Cyril Roelandt <cyril.roelandt@enovance.com>

Implements: blueprint server-group-quotas
DocImpact

Change-Id: Ib281e43eabfbd176454bde7f0622d46fb04fcb79
Imported Translations from Transifex

Change-Id: Ie2d319aed8c16b71a1f17aa4cf7afc649c6151ce
Method for getting NUMA usage from an instance

At present, neither ResourceTracker nor HostManager use objects
consistently. Due to that - we need to handle numa_topology being both
a json blob, instance of VirtNUMATopology, or None at different places
in the code. In addition to that - it can either be a field in a dict,
a NovaObject attribute, or even an attribute on an object that does not
support .get() interface.

Polluting the VirtNUMAHostTopology.get_usage_from_instances breaks
separation of concerns, and is just poor design, but we do need to go
through the same logic in several places, so we add a convenience method
that knows how to deal with all the different combinations described
above.

We also add a separated out method for getting the numa_topology out of
all the possible ways we use instance currently, as it will be useful
for filtering to know if the instance actually has a defined
numa_topology.

Change-Id: I91c3a77153ef8e5e701d3bc7af37ff0a2943fc0c
Blueprint: virt-driver-numa-placement
Merge "Add quotas for Server Groups (V2 API compatibility & V2.1 support)"
Merge "Pass instance to set_instance_error_state vs. uuid"
Merge "Imported Translations from Transifex"
Merge "Method for getting NUMA usage from an instance"