Don't sync [system_]metadata down to cells on instance.save()

A cell should be authoritative for its metadata and system_metadata.
rebuild relis on system_metadata not being updated until the cell
updates it itself.  update_instance_metadata relies on metadata not
being updated so that it can calculate the diff properly.

And before the objects conversion took place the compute.api.update()
method that instance.save() replaced was not used for syncing metadata
or system_metadata.  So this change goes back to previous behaviour for
cells.

Change-Id: I339da9d1ff6d0e59f6a4ab68fd396bdfca7a224b
Closes-bug: #1292181
Closes-bug: #1292185
Move log statement to expose actually info_cache value

When debugging an info_cache issue I noticed the logs  display:

"Updating cache with info: None update_instance_cache_with_nw_info"

Though we are not actually updating the info_cache with None as if
nw_info is not isinstance(NetworkInfo we fetch the latest nw_info
from neturon. This patch just moves the log statement so the actual
value is exposed.

Change-Id: I3a74191c31a053682bb2558c59228025ceb0cf28
Closes-bug: 1292298
Imported Translations from Transifex

Change-Id: Ie9e29d4ee35fc224f9e2f114dfdc6c15ad708e81
Add security_group_rule to objects registry

This adds the security_group_rule module to the objects registry,
which allows a service to make sure that all of its objects are
registered before any could be received over RPC.

We don't really have a test for any of these because of the nature
of how they're imported. Refactoring this later could provide some
incremental steps to making this more testable.

Change-Id: Ie96021f3cdeac6addab21c42a14cd8f136eb0b27
Closes-Bug: #1264816
Fix equal_any() DB API helper

equal_any() query helper is meant to produce a WHERE clause combining
a few conditions with OR operator in order to select the rows for
which the given column is equal to ANY of passed values. In fact,
it uses AND operator instead of OR, which means that an incorrect
WHERE clause will be returned, if more than one value is passed to
equal_any().

This is caused by the fact that the or_() function from SQLAlchemy
expression language is used incorrectly: it accepts unpacked
instances of BinaryExpression, but a list of ones is passed.
Unfortunately, in 0.7.x and 0.8.x branches of SQLAlchemy passing
a list of values to or_() won't raise an exception immidiately,
and the result will be an iterable, which explains why we didn't
see equal_any() was actually broken before. Besides, equal_any() is
rarely used in our code base and the test didn't cover the case when
more than 1 value is passed to the function.

This effectively fixes the error when running Nova unit tests
with SQLAlchemy 0.9.x releases.

Closes-Bug: #1292285

Change-Id: If4c0f1d3e016e2affb0d49293c62ca9df0d033f7
Merge "Add security_group_rule to objects registry"
Merge "Don't sync [system_]metadata down to cells on instance.save()"
Merge "Imported Translations from Transifex"
Merge "Fix equal_any() DB API helper"
Merge "Move log statement to expose actually info_cache value"