Sync iptables rules with an event-driven loop

[hongliangl]

iptables rules were managed with two different mechanisms: most features
only updated their in-memory caches and waited for the 60s periodic sync
to apply them with iptables-restore, while Egress installed and removed
its SNAT rules directly with iptables -I / -D. The periodic sync rewrites
the whole state from the caches, so it could overwrite a SNAT rule
inserted after its snapshot of the caches was taken, leaving the traffic
unSNATed until the next sync, up to 60s later.

The iptables rules are now synced by a dedicated loop, which syncs when a
feature notifies it that the caches have been updated, and when
syncNetworkConfig notifies it on its period. Egress only updates the
caches and notifies the loop instead of writing to the datapath itself,
which removes the race without having to serialize its updates with the
sync.

The notification channel has a buffer of 1 and the loop waits for 100ms
before syncing, so that updates occurring in quick succession are batched
into a single call. Any feature updating the caches can now have its
rules applied about 100ms later, instead of waiting for the next periodic
sync.

syncNetworkConfig notifies the loop after syncing the ipsets, keeping the
existing ordering: iptables rules reference ipsets, and iptables-restore
fails as a whole if one of them is missing.

AddSNATRule and DeleteSNATRule become asynchronous: the rules are applied
about 100ms after the calls return. snatRuleSpec is removed, as the SNAT
rules are now only built by restoreIptablesData.

Signed-off-by: Hongliang Liu hongliang.liu@broadcom.com