Disabling Inter-Container Communication (ICC) in the bridge
driver is implemented using iptables.

The bridge driver has not been checking that iptables/ip6tables
are enabled if required for ICC=false, and some unit tests do
not set up consistent config.

Supplying "netlabel.GenericData" in "options.Generic" form
("map[string]any") does not set up "EnableICC: false". But,
suppling it in "map[string]string" form does - and that's
the form used when a driver option is supplied via the API
as, for example "-o com.docker.network.bridge.enable_icc=false".
So, do that in more tests.

Set EnableIPTables/EnableIP6Tables in the driver config for
other tests, and explicitly enable/disable EnableICC in others.

Signed-off-by: Rob Murray <rob.murray@docker.com>

The integration test helpers like NewSwarm that start a daemon
with swarm enabled have been setting "--iptables=false". Now
deleted comments from 2018 say "avoid networking conflicts".

But, when a swarm network needs a "docker_gwbridge" network,
it's always created with ICC=false, and that can't be implemented
with iptables disabled - the tests have silently been running
with ICC enabled on gateway networks (as well as any other
effects running without iptables may have had).

Non-swarm tests that start their own daemons don't disable
iptables, and CI is happy with iptables enabled.

So, don't disable iptables.

Signed-off-by: Rob Murray <rob.murray@docker.com>

With "-icc=false", no inter-container comms on the default bridge,
the daemon will produce an error and fail to start if iptables or
ip6tables are disabled (and ipv4/ipv6 are enabled for the network).

Add a similar check for user-defined networks, so that "network
create" fails if ICC can't be implemented.

Along with the new errors, test that ICC can be disabled for a
user-defined network.

Signed-off-by: Rob Murray <rob.murray@docker.com>