[CI]: rewrite some container and compose tests

[apostasie]

I have been delaying engaging with compose and container tests so far because of the daunting amount of work...

But at this point, they are the number one contributor to overall slowness (and most of remaining flakyness).
Moving these will cut through the total runtime and make a dent in the bucket of "tests with retries".

Note that we should merge first, before this:
- #4111
- #4081
- #4116

and preferably #4114.

... as this PR does leverage some of the recent changes in Tigron (specifically temp files manipulation).

I will obviously take care of rebasing once they are in, though the last commit of this PR could be reviewed already at this point.

Note that this PR also adopt / cleans-up / remove deprecated helpers (some of them wrongly located under ./cmd, some under ./pkg/testutil).

I know it is painful to review large PRs like that, but I believe there is really no other way here - and at the end of the day, this is only tests - the CI being green is proof in the pudding.

[apostasie]

Failures are:

• [LEGACY] [CI]: TestRestartWithSignal does not seem to (always?) work correctly (EL8 only?) #4068
• [LEGACY] [CI]: ipfs /root/.ipfs/api not available #4118
• windows not happy with TestLogsOutStreamsSeparated anymore

[AkihiroSuda]

Needs rebase

[apostasie]

Rebased.

Thanks for all the merges @AkihiroSuda

I'll do another proof-reading of this right now.

[apostasie]

Failures are a bunch of existing EL8 specific fails.

[apostasie]

Rebasing for good measure.

[apostasie]

Failure is again buildg timeout.

I do not have a good explanation for why we are seeing this so much now.
Intuition would suggest:

• recent update in buildkitd that trips this (also buildg is linking a quite old buildkit fork, so, compat may be an issue)
• recent changes in test.Command which may slightly alter behavior when the streams are attached to buildg (seems unlikely, but then?)
• changes in tests (or otherwise github runner sizing change) that would increase the pressure on the github instance, making for a slower response, that would (now) trip over the timeout (rather short, at 3 secs)

#4103 should get to the root cause eventually, but it is an excruciating process to nail flaky behavior in third party binaries...

[djdongjin]

I hope we can try to reduce PR sizes in future PRs.

I know it is painful to review large PRs like that, but I believe there is really no other way here - and at the end of the day, this is only tests - the CI being green is proof in the pudding.

I would suggest at least split the PR by areas, e.g., one for compose, one for image, one for container.

[apostasie]

I hope we can try to reduce PR sizes in future PRs.

I know it is painful to review large PRs like that, but I believe there is really no other way here - and at the end of the day, this is only tests - the CI being green is proof in the pudding.

I would suggest at least split the PR by areas, e.g., one for compose, one for image, one for container.

That is fair - will do.

Thanks @djdongjin

[AkihiroSuda]

Thanks