[Request]: Add network-scoped aliases for container network attachments

[thromel]

Feature or enhancement request details

Please add network-scoped aliases for container network attachments.

Use case

Higher-level tools such as Compose adapters need to attach additional DNS names to a container on a specific network without changing the container's management name.

For example, a Compose service may have:

services:
  postgres:
    networks:
      backend:
        aliases:
          - db
          - database

The runtime needs a way to represent those names as aliases for the same network attachment so peer containers on backend can resolve postgres, db, and database to the same attachment IP. The aliases should be scoped to the network attachment, not global host DNS.

This complements the broader container-to-container DNS discovery request in #1809.

UX / CLI shape

Use the existing comma-separated --network property syntax and allow repeated alias=NAME entries:

container run --network backend,alias=db,alias=database ...
container create --network backend,alias=db ...

Each alias=NAME applies only to that network attachment. Multiple networks can therefore carry different aliases for the same container.

Proposed design

At a high level:

• Extend network attachment options with an aliases array, alongside the existing primary hostname, MAC address, and MTU options.
• Parse repeated alias=NAME values from the existing --network option grammar.
• Carry aliases through the container API client, persisted attachment configuration, network helper allocation request, and returned attachment metadata.
• Treat the primary hostname and aliases as names for the same allocation in the hostname database.
• Validate duplicate names across active allocations before creating the container, so two attachments cannot claim the same hostname or alias in the same network.
• Normalize aliases using the same hostname lookup behavior as primary attachment hostnames, including case and trailing-dot handling, rather than introducing a stricter validator in this feature.
• Release all names for an allocation when the network attachment is released.

The draft implementation in #1815 follows this shape:

container run --network backend,alias=db,alias=database ...

In live validation against a debug build, peer containers on the same network could resolve the primary container name and both aliases through the container-facing network DNS listener, and a duplicate alias=db failed with the expected duplicate-hostname error.

Code of Conduct

I agree to follow this project's Code of Conduct.