compat: Implement deprecations from Docker API v1.44

[simek-m]

This PR implements API deprecations to be compatible with Docker API v1.44.

• api: Deprecate fields Container and ContainerConfig from GET /images/{name}/json
• api: Deprecate response fields HairpinMode, LinkLocalIPv6Address,
  LinkLocalIPv6PrefixLen, SecondaryIPAddresses, SecondaryIPv6Addresses from GET /containers/{id}/json
• api: Deprecate is-automated filter for the GET /images/search endpoint

Deprecations in Docker Engine API v1.44 API

Deprecated: The is_automated field in the GET /images/search response has been deprecated and will always be set to false in the future because Docker Hub is deprecating the is_automated field in its search API. The deprecation is not versioned, and applies to all API versions.
Deprecated: The is-automated filter for the GET /images/search endpoint. The is_automated field has been deprecated by Docker Hub's search API. Consequently, searching for is-automated=true will yield no results. The deprecation is not versioned, and applies to all API versions.

The fields HairpinMode, LinkLocalIPv6Address, LinkLocalIPv6PrefixLen, SecondaryIPAddresses, SecondaryIPv6Addresses available in NetworkSettings when calling GET /containers/{id}/json are deprecated and will be removed in a future release. You should instead look for the default network in NetworkSettings.Networks.

The Container and ContainerConfig fields in the GET /images/{name}/json response are deprecated and will no longer be included in API v1.45.

Fixes: https://redhat.atlassian.net/browse/RUN-3323

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

- api: is_automated field in the GET /images/search response has been deprecated 
- api: is-automated filter for the GET /images/search endpoint has been deprecated and will be ignored
- api: fields HairpinMode, LinkLocalIPv6Address, LinkLocalIPv6PrefixLen, SecondaryIPAddresses, SecondaryIPv6Addresses available in NetworkSettings when calling GET /containers/{id}/json are deprecated.
- api: Container and ContainerConfig fields in the GET /images/{name}/json response are deprecated

Questions and Notes

• The changes to is_automated are according to the Docker docs not versioned, and apply to all API versions. Hence, I'm not sure if my approach is correct.
• Should there be any warning log? I couldn't find any example of that in the existing code.
• The PR version gated the ContainerConfig field for v1.45 so I kept the version. [compat api] Remove ContainerConfig field #27172
• The test mocked output in search_mock_registry.go includes is_automated and I kept it there.

[simek-m]

It's looks like that the mocked output with is_automated mentioned above is an issue (or the version gate not differentiating between libpod and compat?). I'll fix it.

[+1031s] Summarizing 1 Failure:
[+1031s]   [FAIL] Podman search podman search with mock registry [It] podman search with filter is-automated
[+1031s]   /var/tmp/go/src/github.com/containers/podman/test/e2e/search_test.go:185

EDIT:
Fixed in e6c98e5 and the additional failures appear not to be related to changes in this branch.

[inknos]

Most likely you also want some versioned tests against the compat endpoints like in this previous PR about deprecating endpoints. https://github.com/containers/podman/pull/26213/changes

also, minor thing, the fixup commit could be squashed imho

[inknos]

stated in docker's api

The deprecation is not versioned, and applies to all API versions.

therefore I believe it should just be deleted, not only if version >= 1.44

[inknos]

probably the Automated field should be zeroed out before writing to the response since it's documented to be always false. also, I would verify what docker wants, probably a bool and not a string. Then I would add a specific test for this field and its type

[inknos]

we are not really deprecating this, but we want to touch the compat struct only, which we don't have. Therefore, I believe it's better to create a compat struct with the correct docker types and the deprecation should happen there. this struc is used elsewhere and we don't deprecate this option for the libpod code

[simek-m]

Thank you, @inknos

Regarding is_automated / is-automated:

• How I approached the deprecation is definitely wrong, but I'm now not sure if there should be any other action on the filter side apart from documenting it. My reasoning is that they state searching for is-automated=true will yield no results and it should be transparent to the consumer, i.e. searching for is-automated=true will yield no results.
• Likewise, I'm not sure the is_automated field should be zeroed or be transparent and pass it as it's received (maybe omitempty?). It looks like it's a Docker Hub only thing, though.
• The compat response struct with a deprecation is a very good point, for the record the current response looks like this:

[
  {
    "Index": "docker.io",
    "Name": "docker.io/library/alpine",
    "Description": "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!",
    "Stars": 11509,
    "Official": "[OK]",
    "Automated": "",
    "Tag": ""
  },
  {
    "Index": "docker.io",
    "Name": "docker.io/alpine/git",
    "Description": "A  simple git container running in alpine linux, especially for tiny linux distro.",
    "Stars": 252,
    "Official": "",
    "Automated": "[OK]",
    "Tag": ""
  },
  {
    "Index": "docker.io",
    "Name": "docker.io/alpine/socat",
    "Description": "Run socat command in alpine container",
    "Stars": 115,
    "Official": "",
    "Automated": "[OK]",
    "Tag": ""
  },
  {
    "Index": "docker.io",
    "Name": "docker.io/alpine/curl",
    "Description": "",
    "Stars": 12,
    "Official": "",
    "Automated": "",
    "Tag": ""
  },
  {
    "Index": "docker.io",
    "Name": "docker.io/alpine/helm",
    "Description": "Auto-trigger docker build for kubernetes helm when new release is announced",
    "Stars": 70,
    "Official": "",
    "Automated": "",
    "Tag": ""
  }
]

and the Docker one like this:

[
  {
    "star_count": 11509,
    "is_official": true,
    "name": "alpine",
    "is_automated": false,
    "description": "A minimal Docker image based on Alpine Linux with a complete package index and only 5 MB in size!"
  },
  {
    "star_count": 252,
    "is_official": false,
    "name": "alpine/git",
    "is_automated": false,
    "description": "A  simple git container running in alpine linux, especially for tiny linux distro."
  },
  {
    "star_count": 115,
    "is_official": false,
    "name": "alpine/socat",
    "is_automated": false,
    "description": "Run socat command in alpine container"
  },
  {
    "star_count": 12,
    "is_official": false,
    "name": "alpine/curl",
    "is_automated": false,
    "description": ""
  },
  {
    "star_count": 70,
    "is_official": false,
    "name": "alpine/helm",
    "is_automated": false,
    "description": "Auto-trigger docker build for kubernetes helm when new release is announced"
  }
]

• To compare, the Docker Engine short-circuits the filter and returns an empty result immediately: https://github.com/moby/moby/blob/master/daemon/pkg/registry/search.go#L37

What do you think?

(The fixup commits were not autosquashed, because I'd already opened the PR and wanted to make clear what was changed after and avoid force-pushing.)

EDIT:
Discussed elsewhere and the plan is:

• Introduce compat structure matching the Docker one (can be directly imported).
• Document in Swagger.