Allow _sync_power_states periodic task to hit slave DB

This commit allows those who have slave_connection configured
to have reads from _sync_power_states hit that connection. This
change does not affect anyone who doesn't have a slave. The
behavior remains the same for them.

Implements: blueprint periodic-tasks-to-db-slave
Change-Id: Iaeb2d47a5064a649f427b18d5cbd2b6b97ce90d0
consoleauth: retain havana rpc client compat

48dd52095869d36970de232f5dfa60656fcd578b added v2 of the consoleauth rpc
API and made the client side use it.  However, I forgot to leave in
support for talking the havana API on the client side.  This is needed
for rolling upgrade support.

Related to bleuprint rpc-major-version-updates-icehouse

Change-Id: I30f5651b3f83dcc25639a01513987798a6cdcbb8
Remove consoleauth 1.X rpc api

A previous change adding support for the 2.x rpc interface but retained
compatibility with 1.x as a transition point.  This commit removes the
old API from the server side.

UpgradeImpact

Part of blueprint rpc-major-version-updates-icehouse

Change-Id: I523c3fd605352cb83463a6040ba1f6eb30630810
Adds upper bound checking for flavor create parameters

The flavor-create API does validation that root_gb and
other integer values are positive integers but it doesn't
do an upper bounds check to make sure they aren't longs.
If a user tries to create a flavor with an integer value
that is bigger than an int, the python int() method
(used in the validation) will just convert it to a long but
the database model for InstanceTypes defines the column as
an Integer (not a BigInteger) and then the database has
to handle the value.

This changeset adds upperbounds checking for memory_mb,
vcpus, root_gb, ephemeral_gb and swap.

Also adds missing testcase for ephermal_gb validity

Change-Id: I63ef42e6befeff1edb81bc9caded2df2a4654b8c
Closes-Bug: 1243195
Merge "consoleauth: retain havana rpc client compat"
Merge "Remove consoleauth 1.X rpc api"
Merge "Adds upper bound checking for flavor create parameters"
Merge "Allow _sync_power_states periodic task to hit slave DB"
Return all servers from server create V3 API

The server create API currently returns only one server (the first)
even when multiple servers are requested. In V3, we can change the
API to return a list of servers.

This change returns a list of servers {"servers": [...]} in the
post response instead of only the first server {"server": {...}}.

DocImpact

Closes-Bug: 1187679

Change-Id: I5c833731f1516c8256f835e21cc22fd613bc57ba