Move weave-npc checks to top of FORWARD chain

[bboreham]

We want our DROP rule to be executed ahead of any ACCEPT rules which might have been added by another program on the host.

Since #3204 gave us the framework to ensure we are recreating every rule, just inserting them all at the top, in order, works nicely.

I also moved the NFLOG and DROP rules from FORWARD to WEAVE-NPC to simplify the logic about which order they come in.

Extend kubernetes test to include the circumstances that trigger the issue.

Fixes #3209

[bboreham]

https://circleci.com/gh/weaveworks/weave/9969 is a demonstration of the problem
https://circleci.com/gh/weaveworks/weave/9968 is the same test but without the two factors that trigger it - Kubernetes 1.8.5 and --cluster-cidr argument to kube-proxy

[brb]

I like the idea of the chain simplification, but as discussed on Slack, moving -j DROP to the WEAVE-NPC chain creates a time window for allowing a traffic which should not be allowed by NetworkPolicy, because the weave-npc process clears the chain each time it starts.

However, we have another time window due to -A WEAVE-NPC -m set ! --match-set weave-local-pods dst -j ACCEPT. But this can be fixed by replacing the rule with -A WEAVE-NPC -m set --match-set weave-local-pods src ! --match-set weave-local-pods dst -j ACCEPT.

I suggest to create another level of indirection - a new chain WEAVE-NPC-FOOBAR which would contain -j WEAVE-NPC, "nflog" and -j DROP rules, and insert -j WEAVE-NPC-FOOBAR at the very top of "filter/FORWARD -o weave".

[bboreham]

But this can be fixed by replacing the rule with -A WEAVE-NPC -m set --match-set weave-local-pods src ! --match-set weave-local-pods dst -j ACCEPT.

The idea of this rule was to allow non-pod traffic; that change would disallow non-pod traffic originating on this machine. Maybe that's a niche case.

[brb]

This needs rebasing after #3204 has been merged. Happy to do if you are busy.

[bboreham]

Rebased and simplified.