fix(k8s): issues with querying registries for image tags

[edvald]

What this PR does / why we need it:

This affected users using a non-default deploymentRegistry, as well as
microk8s users. The registry is now properly queried when checking
build status in all cases, both when building locally and remotely,
and whether an in-cluster registry is used or not.

Which issue(s) this PR fixes:

Fixes #1380

[eysi09]

Could you explain the PR a little better. I noticed we bumped the min Docker client version and that we're now downloading the bin if users don't have it. How and why are we using the new Docker version?

[edvald]

Sure. The docker manifests inspect command is only available as an experimental command in the latest major docker release. That command provides a simple way to query registries for info, which we can use to check whether an image/tag exists in a registry. The reason we can't just use an API directly is because of auth. Docker supports a number of auth methods, at least locally (credential helpers and such) and we can't reliably replicate that or use libraries that do.

For the in-cluster building scenario I could have gotten around installing the new version because we exec from the in-cluster builder. The issue there had been that I left an assumption in the build status check that we were using the in-cluster registry. The new flow works for either scenario.

For local builds, this had been an open issue for a while. We'd check for the image in the local docker daemon, and if it existed we'd assume the same image was in the deployment registry. But if something had failed or the tag removed from the deployment registry, users would see issues.

I only realized yesterday that this was causing the problems for microk8s because we use the deployment registry flow there, due to how microk8s is set up.

Changing the minimum required docker version would have been a breaking change, so I needed to fetch docker automatically to address this. I added a bit of extra logic to avoid fetching it when a recent version is already installed, since that's a very common case, and this may otherwise come across as a bit unexpected.

[dcharbonnier]

Suggested change

	return { fresh: true, buildLog: res.output || "", details: { identifier } }
	return { fresh: true, buildLog: res.output ?? "", details: { identifier } }

[edvald]

Ah yes, I keep forgetting that new operator. Makes no semantic difference in this particular case but it's worth keeping in mind.

[eysi09]

LGTM