Bump stable/havana next version to 2013.2.3

Change-Id: Ia5b940faf01df6cae58df1f4b4f5e8fa2f3f078a
Fixing tests to work with keystoneclient 0.6.0

Another item needs mocking with the new release of
python_keystoneclient. Adding it to mocked keystoneclient.Client
object.

Closes-Bug: #1279907
Change-Id: I3c43a7290a6e05c718082dcad369162bf21e3603
(cherry picked from commit 043085f812a1d06e8e082b2dbd52f406172bbfff)
Merge "Fixing tests to work with keystoneclient 0.6.0" into stable/havana
Merge "Bump stable/havana next version to 2013.2.3" into stable/havana
Reduce number of novaclient calls

Currently, each client creates a new session for
each call. This fix makes novaclient re-use
sessions in the most obvoius cases.

Conflicts:
	openstack_dashboard/api/nova.py

Partial-Bug: #1247056

Change-Id: Ie99ecb66304cf40e4f5fdd31fab5162ed11b863e
(cherry picked from commit ddc479272f5402ff778c45892acc3ac7613b7c11)
Allow snapshots of paused and suspended instances

Change-Id: Id483d13d8d329aee4a57d0a89e6368fab3b201ec
Closes-Bug: #1256821
(cherry picked from commit 860b2a0be11ceb2e57c4c0d0e7ff020325277c78)
Don't copy the flavorid when updating flavors

The Nova API makes the implicit assumption that flavorids are unique,
so if one creates two flavors with the same flavorid, subsequent
requests for flavor information can vary between "inaccurate" and
"wildly f*cking inaccurate"

From an end-user perspective, it makes it look like data such as
flavor access settings get lost between edits (because the API pulls
the access list from the wrong flavor)

Let the API assign a new flavorid on changes.  The comments around
the handler code imply that is the desired behaviour, anyhow.

Cherry-picked from 4100a1cbc24184b58d5049dfb601b18e29e6107d

Change-Id: I5403202396a7b136b0ae8637d6aae1cf32550747
Closes-Bug: 1276371
Merge "Reduce number of novaclient calls" into stable/havana
Merge tag 'tags/2013.2.3' into havana

2013.2.3