Fix potential problem in test_router_add_interface_port
Fix potential problem in test_router_add_interface_port

test_router_add_interface_port may fail when an internal metadata
network is created during add_router_interface action.

The potential problem is introduced by Commit 6281fddbcb4c
(https://review.openstack.org/#/c/285048/)
which adds an additional update_port inside add_router_interface()
to update device_id and device_owner on the newly created router port.

The problem could happen when users attach a subnet (for example
10.0.0.0/24) to a router. During the add_router_interface action,
vendor's plugin may create an internal metadata subnet (such as
169.254.169.252/30) and attach it to the same router. Since two
router ports (10.0.0.1 and 169.254.169.253) are created during this
operation, the extra update_port was called on both router ports.

Before Commit 6281fddbcb4c, test_router_add_interface_port only saw
one update_port call on 10.0.0.1. After the change, it now sees three
update_port calls, two on 10.0.0.1 and one on 169.254.169.253.
Because it doesn't expect to see the update_port call on port
169.254.169.253 (which is the last update_port call),
the update_port.assert_called_with() fails.

This patch changes the assert method, so it will check if update_port
has been called on the main router port instead of checking the latest
update_port call is on the main router port.

Change-Id: I0ec1c90ee18bd9d0b027ad462cd6a3c6a079347f
Closes-Bug: #1612896

mahak/neutron,huntxu/neutron,openstack/neutron,noironetworks/neutron,igor-toga/local-snat,noironetworks/neutron,openstack/neutron,mahak/neutron,eayunstack/neutron,sebrandon1/neutron,igor-toga/local-snat,mahak/neutron,huntxu/neutron,cloudbase/neutron,openstack/neutron,sebrandon1/neutron,cloudbase/neutron,eayunstack/neutron