Always filter out multicast from reflection

Instances will try IPv6 neighbour discovery via multicast
even in an IPv4-only cloud and can throw errors
if they see inbound packets from their own MAC address

Closes-bug: #1229625

Change-Id: I3539e788fe07519d87ce7c3800c5d38b7bd99d3b
(cherry picked from commit 9c044d2c94812e18cf84927fbf719cd073fe6c4f)
Fix incorrect root partition size and compatible volume name

When using rbd backend, it needs to resize volume size if size presents. Else
we will get wrong image size.

Rbd volume always uses uuid as the main pattern of volume name, now change to
it is necessary.

This patch also include a follow up fix of the original patch.
https://review.openstack.org/#/c/92512/

Fix bug 1219658

(cherry picked from commit 1b66a47b5f4cbcdf1a9a1ec38532474588a3fee2)

Conflicts:
	nova/virt/libvirt/imagebackend.py

Change-Id: I3dc8d639b066eac35d190b8d4687c41c9f4d5824
Fixes NoneType vcpu list returned by Libvirt driver

* libvirt dom.vcpu may return a NoneType if vcpus dont exist

Change-Id: Iee10c2559ceea636bc4896595962e3470228ad35
Closes-Bug: #1274758
(cherry picked from commit 82821b407ce7a226918758876abca46b727d9706)
Avoid re-adding iptables rules for instances that have disappeared

The remove_filters_for_instance() method fails silently if the
instance's chain is gone (i.e. it's been deleted). If this
happens while we're refreshing security group rules, we will
not notice this case and re-add stale rules for an old instance,
breaking our firewall for new instances.

This adds a quick check after we've captured the lock to see if
the associated chain exists, and bails if it doesn't.

Conflicts:
	nova/virt/firewall.py

Required changes:
- unit test was updated because in Havana, IptablesFirewallDriver has
  .instances instead of .instance_infos, and a separate .network_infos
  attribute.

Change-Id: Ic75988939f82de49735d85fe99a9eecd4baf45c9
Related-bug: #1182131
(cherry picked from commit 6aa368b99249d01f8fd7183c15d11986ad6a6fb7)
(cherry picked from commit 132d5a2064cfdc579a2e51f07e10e8eafbdf6327)
Make floatingip-ip-delete atomic with neutron

The infra guys were noticing an issue where they were leaking floating ip
addresses. One of the reasons this would occur for them is they called
nova floating-ip-delete which first disassocates the floating-ip in neutron
and then deletes it. Because nova-api makes two calls to neutron if the
first one succeeds and the second fails it results in the instance no longer
being associated with the floatingip. They have retry logic but they base it on
the instance and when they go to retry cleaning up the instance the floatingip
is no longer on the instance so they never delete it.

This patch fixes this issue by creating a new method
disassocate_and_delete_floating_ip which contains the different logic
needed to atomically do this for neutron rather than putting the logic
in the api layer to do something differently if one is using neutron.

This patch also adds additional code coverage for nova-network in the
delete floatingip case.

Closes-bug: 1356157

Conflicts:
	nova/api/openstack/compute/contrib/floating_ips.py
	nova/network/base_api.py

Change-Id: I53b0c9d949404288e8687b304361a74b53d69ef3
(cherry picked from commit 5f391087d1d75dd4e7532252c312256e9c3ea2b9)
Merge "Always filter out multicast from reflection" into stable/havana
Merge "Fixes NoneType vcpu list returned by Libvirt driver" into stable/havana
Merge "Fix incorrect root partition size and compatible volume name" into stable/havana
Merge "Avoid re-adding iptables rules for instances that have disappeared" into stable/havana
Merge "Make floatingip-ip-delete atomic with neutron" into stable/havana