Port server_diagnostics extension to v3 API Part1

This changeset only copies the v2 files (implementation and test)
into the appropriate v3 directories unchanged. The copy as-is
will not be loaded by either the v2 or v3 extension loaders. The
second changeset will then make the changes required for it to
work as a v3 extension.

This is being done in order to make reviewing of extension porting
easier as gerrit will display only what is actually changed for v3
rather than entirely new files

Implements blueprint nova-v3-api

Change-Id: I52f906948b5873cf3fdfff14270c7384ee5e7b9f
db.compute_node_update: ignore values['update_at']

When individual instances are updated (e.g., during spawn and
terminate), ResourceTracker (in nova.compute.resource_tracker)  calls
compute_node_update with values=self.compute_node. Since
self.compute_node is an instance of ComputeNode that was retrieved
from the database, it has updated_at set. Since updated_at is in
values, sqlalchemy doesn't automatically change the record's
updated_at column (see
nova.openstack.common.db.sqlalchemy.models.TimestampMixin). Moreover,
since updated_at is set to the last value's updated_at, updated_at
effectively doesn't change until values without updated_at are sent,
which only happens during the periodic task that calls
ResourceTracker.update_available_resources.

Nova-scheduler relies on ComputeNode.updated_at to keep its model of
available resources up-to-date. In particular, nova-scheduler doesn't
play a role in instance termination, so it doesn't account for freed
resources until ComputeNode.updated_at changes. Thus, between
nova-compute's periodic calls to
ResourceTracker.update_available_resources, nova-scheduler's model of
available resources monotonically decreases. If, for example, a node
has resources for 10 instances, and you manage to boot 10, terminate
10, then attempt to boot another before the end of the period,
nova-scheduler won't schedule the new instance on the vacant node.

Fixes bug #1194900.

Note that f398b9e195cda582bad57396b097dec274384c07 fixed a separate
issue (bug #1153778) related to ComputeNode.update_at being stale.

Change-Id: Ifd1e56edfd811241816970715071876857de80d3
Allow retrying network allocations separately

Introduce a new config option, 'network_allocate_retries', that allows
one to retry network allocations.  The default is 0 for no retries to
match the current behavior.

The network allocations currently get retried by a full retry of a build
via the scheduler, if those are enabled.  This patch reduces the need to
re-schedule for simple network allocation issues.

The retrying happens in the network alloc async greenthread, so for virt
drivers that support the new NetworkModel, the retrying potentially
happens in the background while the image is being downloaded, etc.

DocImpact

Change-Id: I1a5fdcccbb736fc0b1d8c0cbc3b45a8372a6aef7
Merge "db.compute_node_update: ignore values['update_at']"
Merge "Allow retrying network allocations separately"
Merge "Port server_diagnostics extension to v3 API Part1"
Merge remote-tracking branch 'm_src_repo/citrix-fixes' into build-temp