Prepare ground for moving on new API

[avagin]

This series allows to start an init process in a new CT. In this version CT isn't created actually. This will be done in future patches.

I need to get answers on a few questions to continue this work.

1. StartProcess() starts a process inside the container.
   If the container isn't started yet, this function will create a process in a new set of namespaces.
   If the container is running, a new process will be created in the set of namespaces which belong to the container.
   If all processes in the CT have died, this function will create a process in a new set of namespaces ().
   If all those statements are true, it looks strange that we don't want to know when a new container is created and when a process is executed in an existing container.
2. How to follow container's state? We return PID-s of processes to users, so we can't call the waitpid() syscall for them. Are we going to monitor cgroup file system events or something like this?
3. Are we going to support containers without pidns? In this case State.Init Pid looks meaningless.
4. Are we going to support "permanent" containers? A "permanent" container is a container which can live without processes. For example the ip utility creates such containers "ip netns add test". In this case /proc/pid/ns/* files should be bind-mounted to somewhere and these links are used for setns().

[vmarmol]

Answering your questions:

1. The factory has a Create() this creates everything in the container that is not tied to the init process (e.g.: cgroup, root directory, most namespaces). The first call to container's StartProcess() should do all the process specific setup (e.g.: userns, pidns). Subsequent StartProcess() just start a process in the existing container. If the init dies, then the container is empty and a subsequent StartProcess() re-starts the state tied to the init process.
2. You can call RunState which in turn may query the cgroups to find out if the container still exists. Is this what you meant?
3. We may share pid ns with another container. In these cases InitPid may be empty.
4. Yes, all containers will be permanent as per (1).

@crosbymichael in case he doesn't agree with any of the above. But I believe we have from what we've spoken about before.

[vmarmol]

this shouldn't need to be in the public API no?

[avagin]

I think it should. When CT is created, a new process is forked in a new set of namespaces and this process must call execve() immediately. So an user of libcontainer has to create a program which will be executed in a new set of namespaces and call StartInitialization(). For example "nsexec init" will call this method.

[vmarmol]

(I'm fine as is for the sake of progress, but:) shouldn't the library handle this? As in, I want to run "echo hello" in my container. Shouldn't the library to the fork/exec/sync and then re-exec my "echo hello"?

[vmarmol]

You'll need to sign your commits since Travis is complaining.

[vmarmol]

LGTM, please sign your commits and we can merge. Thanks for the patch! It is smaller and simpler than I thought it'd need to be.

[avagin]

@vmarmol I have signed my commits. Thanks.

[vmarmol]

The CI is complaining that some files are not gofmt'ed mind running it through that? This LGTM, we're just waiting on having the CI go green.

[vmarmol]

Thanks @avagin! LGTM, merging.