Fixes a race condition on updating security group rules

During creating the instance, compute manager makes an rpc call
to "allocate_for_instance" from the network manager, which will
in turn end up making a rpc cast to each compute_manager with
an instance in the group(s) than need to be refreshed calling
refresh_instance_security_rules.

When an instance is being created is in a group that has a
rule referring to itself, that chain will end up trying to
refresh the rules for the instance which is still being created.

That call will find its way down to do_refresh_instance_rules()
in libvirt/firewall - which will in turn try to get network_info
from the global "network_infos" in firewall.

But the entry in network_infos for this instance might not of
been added yet, as that only happens when the create of the
instance calls "prepare_instance_filter which comes later in
the sequence as part of driver.spawn

The fix here adds a synchronisation lock to the incomming
refresh call so that it is blocked until any in-progress
thread on the instance is finished.

Change-Id: I550e286aa4777b011633550109e18e03d63a4bbb
Update nova/compute/api to handle instance as dict

When nova.dp.api returns primitives instead of sqlalchemy objects
instance objects will be dictionaries, which cannot be added to sets
('dict' is an unhashable type)

Partially implements bp db-api-cleanup

Change-Id: I3683d1c54ae627d9cabfd569a7fd304c47c5d5b7
Merge pull request #33 from zarnovican-gd/bza_secgroup

PCI-3066 - Slow and non-reliable security groups in Folsom