No internal package use in tests

[TBBle]

Based on a comment I made earlier in #1073, I had a look at it would take to enforce a "No imports from internal in tests" policy.

A couple of easy, self-contained packages to make public fell out, but then the next thing I wanted to make public was internal/cmd, and it exposes a couple of types in its APIs from internal/cow and internal/uvm, and the dependency graph explodes at that point, even before I looked at test/functional/wcow_test.go which pulls 10 different packages from internal plus hcsshim itself, probably because of

hcsshim/test/functional/wcow_test.go

Lines 29 to 36 in 1f8211a

	// Has testing for Windows containers using both the older hcsshim methods,
	// and the newer hcsoci methods. Does the same thing in six different ways:
	// - hcsshim/argon
	// - hcsshim/xenon
	// - hcsoci/argon v1
	// - hcsoci/xenon v1
	// - hcsoci/argon v2
	// - hcsoci/xenon v2

which leaps-out as a super-code smell if it's testing old and new interfaces, and the entire "new" interface is not public.

So I'm posting this for direction/consideration/ideation:

• Both of the existing changes (<dropped in favour of Export hcsshim annotations into its own package #1201> and fbffeaa) have some alternative approaches listed.
• I still think using pkg/ for publishing ociwclayer was a mistake, but I guess it does send the signal that this is intended to be a more-stable API, within the constraints of the current v0.x version. (It also sends the signal that I was using last decade's best-practice due to learning Go from old tutorials). And Export hcsshim annotations into its own package #1201 has doubled down on this, so I guess this is where we're going now.
• Similarly to the current state of internal/hcs/schema should probably not be internal, or needs more wrapping functions. #1073, I'm not sure if we want to go wide on publishing modules, go narrow using a lot of type aliases, or even consider a bunch of helper functions to expose/wrap internal APIs.
• It's possible that I'm wrongheaded about this, and the preference is to keep these modules mostly internal, in order to drive users via containerd-shim and similar utilities. In this case, I can drop this experiment, and focus narrowly on getting the layer manipulation code (which doesn't have a wrapper, e.g., containerd imports it directly) sorted out for v2, which are blocked for me on internal/hcs/schema should probably not be internal, or needs more wrapping functions. #1073 and How is read-write layer mounting done on the host with computestorage? #1076, but are not blocked by this work particularly.

[TBBle]

If I or someone else ever come back to this, I saw a neat trick in the Go source itself, of having an _test.go-suffixed file that only exports internal symbols for use in tests. It might not help here, but did remind me of this experiment.