info: add Features field to show feature-configuration

[thaJeztah]

• relates to introduce Containerd-snapshotter feature flag #43735
• relates to emptyfs: Use newer image layout rumpl/moby#31

This adds a new Features field for API v1.43 and up, which contains the current
configuration of features that have been either enabled or disabled in the daemon
configuration.

With this patch:

mkdir -p /etc/docker
echo '{"features":{"containerd-snapshotter":true}}' > /etc/docker/daemon.json
dockerd &

curl -s  --unix-socket /var/run/docker.sock http://localhost/info | jq .Features
[
  "containerd-snapshotter=enabled"
]

- Description for the changelog

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

[thaJeztah]

I should add that this shows the configuration currently; wondering if we would need to change this to show the current status (e.g. for features that are enabled by default)

[thaJeztah]

We discussed this in the maintainers meeting;

• the only two options currently available are buildkit and containerd-snapshotter
• the buildkit option will become less (non) relevant soon (also see api: set default "Builder-Version" to "2" (BuildKit) on Linux #43657), but also is already exposed through the API (as builder-version)
• for the containerd-snapshotter, it might be more relevant to show;
  • the default snapshotter used for containerd (which basically can replace the GraphDriver field)
  • the list of available / supported snapshotter plugins (as detected by containerd), which may be more relevant to users
• having a list of features therefore currently has no real use-case, other than for the test-case in emptyfs: Use newer image layout rumpl/moby#31, which can also be addressed by the GraphDriver field if we would propagate that.

Moving this back to draft, and I'll have a look at exposing the information as GraphDriver and/or GraphDriver metadata instead

[AkihiroSuda]

Just having labels (with a prefix like com.docker.engine.features/) might be enough for this?

[rumpl]

having a list of features therefore currently has no real use-case, other than for the test-case in

One real use case for the features list is for buildx: it can use this information to know if its docker driver can support multi-platform images

[rumpl]

Any reason this is a []string with a micro-format instead of a map[string]bool?

[ndeloof]

either map[string]bool or map[string]string (for status, enabled| disabled | ..)
but please don't use yet another string microformat within a JSON API

[thaJeztah]

Yeah, this was a 5 minute, quick implementation for discussion in the maintainers call; we did discuss using a map instead (possibly with custom marshaling to return a consistent order in the API response)

But then we also discussed if we really wanted this, because

• these options don't reflect the current state of these features (only if they're overridden)
• for the builder version; this is already exposed through other ways
• for the snapshotters, it'll be more useful to know what snapshotter is used (and what other snapshotters are available); both of those would effectively replace what "graphdriver" is currently showing, so the preference was to explore using that instead.

w.r.t. buildx; I wonder if that's information that should be part of the buildkit API 🤔 (/cc @crazy-max )

[thaJeztah]

closing in favour of #43983