Convert SpecGen values to be nullable where possible

[mheon]

SpecGen is our primary container creation abstraction, and is used to connect our CLI to the Libpod container creation backend. Because container creation has a million options (I exaggerate only slightly), the struct is composed of several other structs, many of which are quite large.

The core problem is that SpecGen is also an API type - it's used in remote Podman. There, we have a client and a server, and we want to respect the server's containers.conf. But how do we tell what parts of SpecGen were set by the client explicitly, and what parts were not? If we're not using nullable values, an explicit empty string and a value never being set are identical - and we can't tell if it's safe to grab a default from the server's containers.conf.

Fortunately, we only really need to do this for booleans. An empty string is sufficient to tell us that a string was unset (even if the user explicitly gave us an empty string for an option, filling in a default from the config file is acceptable). This makes things a lot simpler. My initial attempt at this changed everything, including strings, and it was far larger and more painful.

Also, begin the first steps of removing all uses of containers.conf defaults from client-side. Two are gone entirely, the rest are marked as remove-when-possible.

Marking as release note none for now, because this may not actually be a breaking change to our API, given how lenient Go's JSON parsing has always been.

[NO NEW TESTS NEEDED] This is just a refactor.

Does this PR introduce a user-facing change?

NONE

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mheon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Cockpit tests failed for commit 5e2b2407743adf0aecba4248e6ba2e8586acc65e. @martinpitt, @jelly, @mvollmer please check.

[packit-as-a-service]

Cockpit tests failed for commit f1ab0e70525b8fe7717e18c989bdfc168233d9cf. @martinpitt, @jelly, @mvollmer please check.

[packit-as-a-service]

Cockpit tests failed for commit a9e924e56854a1730acc6eb6b4b3186cce524458. @martinpitt, @jelly, @mvollmer please check.

[martinpitt]

The cockpit failure here is much less severe than in #21308.

wait_js_cond(ph_in_text(".pf-v5-c-alert","address already in use")): actual text: Danger alert:Container failed to be created Error message: Internal Server Error: invalid config provided: invalid ImageVolumeMode "bind", value must be one of ignore,tmpfs,anonymous

This test creates a first container with exposing port 5000 on the CLI ( -p 5000:5000) and then tries to create a container in the UI with also exposing port 5000, and expects that "address already in use" error message. Instead it fails with that curious one -- bind should certainly be a valid volume mode, and it does work in other cases as well?

Is that enough for you to spot the error, or do you need a curl reproducer?

[mheon]

containers/common#1820 (once merged and vendored) will fix the image-volume issue. The containers.conf default is not sane and needs to be changed.

[mheon]

Vendored our updated c/common

[packit-as-a-service]

Cockpit tests failed for commit d7378f97e0c8ec93a554c020f11c18d6c1f4d684. @martinpitt, @jelly, @mvollmer please check.

[ashley-cui]

/hold
/lgtm

[packit-as-a-service]

Cockpit tests failed for commit 885c65319254a9f97af8158a2739ebdcfc5734c8. @martinpitt, @jelly, @mvollmer please check.

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[baude]

/lgtm

hold is already present

[baude]

/hold cancel