Remove the docker runtime and docker-bridge network providers

[luxas]

Fully base Ignite on containerd/CNI-only, and get rid of the extra docker imports.
Will result in a cleaner, leaner and more understandable codebase.
cc @chanwit

[chanwit]

roger!

[chanwit]

@stealthybox what we have planned now conflicts with this issue. could you please remove v0.7.0 milestone out of this one.

[luxas]

Why does it conflict? I think we should try to do forward-fixes instead of keeping the older code

[chanwit]

the docker runtime makes it a breeze experience for Ignite users but it's still a bit difficult for the containerd runtime to have on-par UX.

If a goal is to have the best UX for people to try VMs with Ignite, let's not too hurry to remove docker :-)

[chanwit]

Alternatively, if we could ship containerd along with ignited, and the UX is improved. We could finally remove docker dependency. WDYT? cc @luxas @twelho @stealthybox

ref #399

[stealthybox]

I'm less worried about containerd as the runtime now that #411 copes well with different versions and installs.

docker+docker-bridge works OOTB for many users.

docker+cni works except for #393.
containerd+cni is currently not working -- this is our next priority.

Once everything with CNI is fixed and we have packaging and installation polished, I think we can begin to consider this.

It's worth noting that ignite leaves behind a lot of containers right now when we hit bugs managing ignite vm state. This causes ignite to orphan containers and dm snapshots.
The ctr CLI is necessary to clean these up in containerd. ctr is an undocumented, hacky dev tool that is not widely known.

docker has a supported, versioned, CLI, and people know how to use it.

Implementing ignite clean using the containerd API's and dmsetup remove_all would probably be necessary.
As a user I don't know how to manually cleanup after CNI.

[stealthybox]

Adding another CNI issue: #423

[stealthybox]

Also see #436 regarding CNI startup time