Add our own integration test framework.

[Random-Liu]

Currently, we are relying on CRI validation test and Kubernetes node e2e test. And in the future we'll run Kubernetes cluster e2e test.

However, there are many functionalities could not be covered by these tests:

1. cri-containerd inside runtime cgroup;
2. containerd-shim inside pod cgroup;
3. cri-containerd restart;
4. apparmor/seccomp default
5. ...

We should have our own test framework for these test cases.

[mikebrow]

1. agree with the need for integration testing but would like over time to have it all back into CRI validation or e2e as we enhance those buckets and the CRI.
2. I did the initial code for runc's integration bucket. We decided to use bats. That worked out ok I suppose cause it was all command line. Not sure what the state of the art is right now. Any ideas for what you'd like to use? I see critools is all in go. That would work I guess.

[Random-Liu]

@mikebrow In Kubernetes, we are using ginkgo. In containerd, they are using golang test directly.

In either case, I think we should use a golang based test framework, which Kubernetes and containerd contributors are familiar with. I think ginkgo should be fine. We could reuse some of critools' test framework.

In my mind, critools' test framework should be shared by different cri implementations. And critools itself only ships with non-runtime specific test. /cc @feiskyer

[mikebrow]

sounds good

[feiskyer]

In my mind, critools' test framework should be shared by different cri implementations. And critools itself only ships with non-runtime specific test. /cc @feiskyer

Yep, cri-tools doesn't depend on any specific runtimes.