api: Make EnableIPv6 optional (impl #2 - Option-based)

[akerouanton]

• This is an alternative implementation of api: Make EnableIPv6 optional (impl #1 - pointer-based) #47867.
  • api: Make EnableIPv6 optional (impl #1 - pointer-based) #47867 uses a bool pointer to make the field EnableIPv6 optional.
  • This PR uses a Rust-like Option type to make the field optional.

- What I did

Currently, starting dockerd with --default-network-opt=bridge=com.docker.network.enable_ipv6=true has no effect as NetworkCreateRequest.EnableIPv6 is a basic bool.

This change uses a Rust-like Option type to mark the field as optional. If clients don't specify it, the default-network-opt will be applied if it's specified, otherwise it defaults to false.

- How to verify it

CI -- a new integration test has been added but will fail until #47853 is merged.

- Description for the changelog

- IPv6 can now be enabled by default on all custom networks using `dockerd --default-network-opt=bridge=com.docker.network.enable_ipv6=true` (and the matching json option).

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

[corhere]

This is way more straightforward than #47867! No worrying about accidentally aliasing variables; it's just a value with value semantics.

[corhere]

Suggested change

	EnableIPv6 optional.Option[bool] // EnableIPv6 represents whether to enable IPv6.
	EnableIPv6 optional.Option[bool] `json:",omitempty"` // EnableIPv6 represents whether to enable IPv6.

to suppress marhsalling {"EnableIPv6": null}.

[akerouanton]

Discussed during today's maintainers call and internally. Overall, everyone agrees Option[T] is a good thing as compared to pointer-based optional fields. However, there's some pushback as this would make the API inconsistent (ie. vs what we already do for other fields), and introducing a new dependency which isn't widely picked by the community isn't great.

We might still do that change at a latter time, but for all optional fields at once. And the 2nd problem could be overcomed by the use of an interface to not force a specific implementation.

Since #47867 has been merged, let's close this one.

[corhere]

And the 2nd problem could be overcomed by the use of an interface to not force a specific implementation.

Interfaces are reference types, which have the same aliasing issues as plain pointers. I suggested adding a concrete facade type to the github.com/docker/docker/api package to allow us to swap out the underlying implementation without it being a breaking change. E.g.:

type Option[T] struct { v optional.Option[T] }

func (o Option[T]) IsSome() bool { return o.v.IsSome() }
func (o option[T]) IsNone() bool { return o.v.IsNone() }
// etc...