testutil: make testing packages public

[SamWhited]

- What I did

Moved /internal/test and /internal/testutil into /testutil so that it can be used from within buildkit.

- How I did it

Moved it and sed-ed all of the import paths and package names.

- How to verify it

Hopefully CI should pass and git should show that most files are just moved and not modified heavily.

- Description for the changelog

The testutil package is now public and can be used to spawn docker daemons for testing.

- A picture of a cute animal (not mandatory but encouraged)

[tiborvass]

Thanks @SamWhited! For posterity I like to put in the commit message at least, the exact sed command used.

[SamWhited]

Sure. It was something along the lines of:

mv internal/test testutil                                                                                                                                                                               
pushd testutil/; grep -IRl "package test" | xargs -I '{}' sed -i -e 's|package test|package testutil|g' {}; popd                                                                                        
mv internal/testutil/*.go testutil/ && rm -rf internal/                                                                                                                                                 
grep -IRl "github.com\/docker\/docker\/internal\/test" | xargs -I '{}' sed -i -e 's|github.com/docker/docker/internal/test|github.com/docker/docker/test|g' {}                                          

That may not be exact, I copied a few lines out of my bash history. I'll throw this in the commit message after CI finishes (I don't want to interrupt it)

[SamWhited]

Two things still failing in CI, one appears to be the Windows issue that I believe is being worked on in another PR, the other doesn't appear to be related but I'm not sure why it's failing now. Will dig in as soon as I'm done with some of the buildkit changes.

[SamWhited]

Looks like running goimports makes a lot of changes (including breaking ones because it gets confused by module version suffixes), fixing only the ones that were the result of the package rename to try and make things work for now.

[SamWhited]

Remaining test failures are the windows failures which I think are failing in general right now and aren't related. PTAL. Thanks!

[SamWhited]

Running tests on Windows appears to be failing for different reasons now, looking into it to see if it's my fault or not. They do appear to be failing (sometimes?) on master too, so maybe it's just flaky. If anyone is familiar with windows tests and what the state of testing on master is right now your input would be appreciated. Thanks! /cc @tiborvass, @thaJeztah

EDIT: Ran it again and it's not a timeout anymore, it's EC2 failing so I'm going to go out on a limb and say this is just flaky right now.

[SamWhited]

Rebased on top of Tibor's testing change. Waiting on CI to see if I missed anything or broken an import.

[thaJeztah]

LGTM

[SamWhited]

Pushed a change to add import lines back as requested by @thaJeztah; PTAL, thanks!

[thaJeztah]

LGTM

let's create a tracking issue to validate that each package has a (correct) import comment

[SamWhited]

@thaJeztah done, see #39898

[thaJeztah]

Oh, sorry; this needs a rebase now; I see #39886 was merged, which caused a conflict

[thaJeztah]

Only failure was on Windows RS1, and a known flaky test (on slow platforms?) #38521;

     --- FAIL: Test/DockerSuite/TestStartReturnCorrectExitCode (7.62s)
         docker_cli_start_test.go:198: assertion failed: 125 (exitCode int) != 12 (int): out: time="2019-09-11T00:09:35Z" level=error msg="error waiting for container: EOF" 

[SamWhited]

@thaJeztah rebased

[thaJeztah]

Windows RS1 failure is a Jenkins issue; https://ci.docker.com/public/job/moby/job/PR-39829/17/execution/node/72/log/

 azwin-2-102ef0 was marked offline: Connection was broken: java.util.concurrent.TimeoutException: Ping started at 1568206049555 hasn't completed by 1568206289556
 	at hudson.remoting.PingThread.ping(PingThread.java:134)
 	at hudson.remoting.PingThread.run(PingThread.java:90)

Gonna ignore that one