libcontainer: move capabilities to separate package

[thaJeztah]

I had these changes open in the branch I used for #2595. TBH, I don't exactly recall why I made these changes, but I guess because it's slightly cleaner to have it in a separate package (similar to cgroups, devices, apparmor, etc all being separate).

I'm not super-attached to it, so feel free to close if you don't like this change, but thought I'd push it to give the opportunity to review 😅

@kolyshkin @AkihiroSuda

[kolyshkin]

While at it, we might start using internal to make sure no other package (except runc) starts using this package.

I am split between the top-level internal and libcontainer/internal. In this very case I'm in favor of the latter.

[kolyshkin]

internal is already used in #2569

[kolyshkin]

I don't exactly recall why I made these changes

Probably because of func init() in libcontainer/capabilities_linux.go, so it won't be always run.

I just found myself creating an alternative to this one: #2646

[thaJeztah]

Ah, yes, avoiding init is definitely good. I still think that having it in a separate package is clean (not critical of course); slightly on the fence on using "internal" (which would hard restrict external users); guess "libcontainer" is now a bit of a confusing name, as it's no longer meant to use as a library (by others)

[AkihiroSuda]

What's current status?

[thaJeztah]

@kolyshkin good to go?

[AkihiroSuda]

Could you rebase to retrigger CI?

[thaJeztah]

rebased 👍

[thaJeztah]

@kolyshkin @crosbymichael PTAL; this one good to go?

[thaJeztah]

rebased.

@AkihiroSuda @kolyshkin @crosbymichael PTAL; this one good to go?

[AkihiroSuda]

@cyphar @kolyshkin Can we have this in rc93?

[cyphar]

LGTM. Regarding internal I think we should move basically all of libcontainer into internal at some point and move the bits of code people actually use to be outside internal, so that the default state of libcontainer is private.