Process port_update notifications in the main agent loop

Instead of processing a port update notification directly in
the RPC call, the actual processing is moved into the main
rpc loop, whereas the RPC call just adds the updated port
identifier to a set of updated ports.
In this way, a port_update notification won't compete with the
main rpc loop, causing long delays into its completion under
heavy load. Also, repeated port_update notifications received
within a single iteration of the main agent loop will be
coalesced and processed only once.
This will also avoid the risk of processing notifications out
of order thus ending up with an actual configuration which
differs from the desired one.

This patch still performs L2 wiring for updated ports even if
it is necessary only when the administrative state of a port
changes.

The update_ports method has been renamed to scan_ports as the latter
name appears to be more in line with what the method actually does.

Partial-Bug: #1253993
Partially implements blueprint: neutron-tempest-parallel
Change-Id: I219c6bdf63b0b5e945b655677f9e28fa591f03cd
Improve handling of security group updates

Currently updates to security group rules or memebership
are handled by immediately triggering a call to refresh_firewall.
This call is quite expensive, and it is often executed with a
very high frequency.

With this patch, the notification handler simply adds devices for
which the firewall should be refreshed to a set, which will then
be processed in another routine. The latter is supposed to
be called in the main agent loop.

This patch for 'provider updates' simply sets a flag for refreshing
the firewall for all devices.

In order to avoid breaking other agents leveraging the security
group RPC mixin, the reactive behaviour is still available, and is
still the default way of handling security group updates.

Partial-Bug: #1253993
Partially implements blueprint: neutron-tempest-parallel

Change-Id: I1574544734865506ff5383404516cc9349c16ec4