Establish cadence for regularly updating CNI

[mikebrow]

Need to decide when to update CNI and establish a cadence process.

• coordinate updating cni and plugins across the stack
  bump containernetworking/cni to v0.8.0 #56

• evaluate new cni cache config apis

[fuweid]

What is new cni cache config apis here? :)

[mikebrow]

New stuff to look at for cni
containernetworking/cni#661
Adds an api for:

"Cache the config JSON, CNI_ARGs, and CapabilityArgs on ADD operations,
and remove them on DEL. This allows runtimes to retrieve the cached
information to ensure that the pod is given the same config and options
on DEL as it was given on ADD."
"So @squeed and I talked about it for a while, and decided that yes there are use-cases for changing parts of a given network config underneath the container, but not for switching the network config out entirely. So much like @mars1024 is saying, a delete operation should probably only check network name (and perhaps plugin type) from the config its sending and make sure those match."
"I think the config caching that this PR does is probably OK, since all it does is allow the runtime (dockershim, crio, etc) to retrieve that config. Then the runtime can make the decision about whether to use an existing updated configuration that it already knows about, or if that's no longer valid (eg old config deleted entirely) it could use the cached config."
"Does that sound OK to everyone? eg libcni only does the storage/retrieval, while the runtime itself can make policy decisions about how to handle config changes."

new stuff for plugins:
Check support
containernetworking/plugins#264

New plugins:
bandwidth - limit incoming and outgoing bandwidth (#96), (#138).
firewall - add containers to firewall rules (#290).
sbr - convert container routes to source-based routes (#212).
static - assign a fixed IP address (#136), (#165).
win-bridge, win-overlay: Windows plugins (#193), (#215).