libct: internalize some packages

[kolyshkin]

This moves a few packages from libcontainer to internal, so that they are no longer available to external users. This is the first step in implementing #3028.

I chose internal over, say, libcontainer/internal or pkg/internal merely because of a short path.

[kolyshkin]

Hope this won't conflict with #3033 as it will be a nightmare to rebase that one.

[kolyshkin]

Are there any objections or comments about this PR, @opencontainers/runc-maintainers? I have another PR (#3056) that is based on this one and want to move forward with it.

[hqhq]

I personally prefer libcontainer/internal, because libcontainer is supposed to be the library of container, even these files are moved to internal, they should still be part of the "library of container".

[kolyshkin]

I personally prefer libcontainer/internal, because libcontainer is supposed to be the library of container, even these files are moved to internal, they should still be part of the "library of container".

First, I was hoping to make those import paths shorter (or at least not longer).

Second, runc/libcontainer is used by other projects, while runc/internal clearly contains a set of packages aimed for runc itself. Are those packages about containers? Yes, they are -- the whole runc is, and no, they aren't -- say, capabilities package is about process caps, and is not really about containers per se.

I'd like to keep it as is (mostly because it's shorter).

[hqhq]

I personally prefer libcontainer/internal, because libcontainer is supposed to be the library of container, even these files are moved to internal, they should still be part of the "library of container".

First, I was hoping to make those import paths shorter (or at least not longer).

Second, runc/libcontainer is used by other projects, while runc/internal clearly contains a set of packages aimed for runc itself. Are those packages about containers? Yes, they are -- the whole runc is, and no, they aren't -- say, capabilities package is about process caps, and is not really about containers per se.

Yes, everything in runc repo is about container, but the phrase I used was library of container,
it's different with just container.

Back to the old days, we only have libcontainer, then we moved it to a separate repo to build runc based
on it, runc only added very limited things, the most important part is the cli, other than that, just minor
things like scripts, test cases, docs, man pages, etc.

According to #3028 , we are about to move most of libcontainer packages to internal, which means we are
removing the ability to create containers just by importing libcontainer and using its APIs, it's fine to me if
nobody is doing so. But I think we can still keep libcontainer as independent, it's kind of the core of container
runtime.

I'm happy to change my mind if there are other concerns, just shorter path isn't a compelling reason for me.
@cyphar @crosbymichael WDYT?

I'd like to keep it as is (mostly because it's shorter).

[kolyshkin]

draft until we decide on the path.

[kolyshkin]

No consensus on the path for internal packages, so I'm closing this one.