apt_repository can only emit the deprecated one-line sources format

Describe the Enhancement:

apt_repository can only emit the one-line (legacy) sources format. There is no way to opt into the deb822 .sources format.

The format is hardcoded in build_repo, which always builds deb <options> <uri> <suite> <components> lines:

https://github.com/chef/chef/blob/61ad886b693750869d2b45d5ec6473dc26d3d251/lib/chef/resource/apt_repository.rb#L513-L530

and the result is always written to <repo_name>.list:

https://github.com/chef/chef/blob/61ad886b693750869d2b45d5ec6473dc26d3d251/lib/chef/resource/apt_repository.rb#L600-L609

APT has supported deb822 since 1.1, and sources.list(5) now says of the one-line format:

This format is deprecated and may eventually be removed, but not before 2029.

Debian and Ubuntu are actively migrating. Ubuntu ships its own archive definition as a deb822 /etc/apt/sources.list.d/ubuntu.sources, recent APT provides apt modernize-sources to convert legacy files, and APT emits a notice recommending it when .list files are present.

There is also a concrete correctness problem today, independent of the format preference.

If an operator runs apt modernize-sources on a host that Chef manages, a Chef-owned foo.list is converted to foo.sources. On the next converge:

1. action :add does not look for foo.sources, so it recreates foo.list. The same URI is now configured twice and APT warns about duplicate sources.

2. action :remove only ever tests for and deletes foo.list:

   https://github.com/chef/chef/blob/61ad886b693750869d2b45d5ec6473dc26d3d251/lib/chef/resource/apt_repository.rb#L612-L637

   Because foo.list is gone, the guard falls through to logger.debug("... does not exist. Nothing to do") and the resource reports success while the repository remains configured in foo.sources. :remove silently fails to remove the repository.

Point 2 affects users now, on any release where APT suggests modernization, and is arguably a bug rather than an enhancement.

Proposal

Add an opt-in property (for example deb822 true, defaulting to false) so existing behavior is unchanged. When enabled, write /etc/apt/sources.list.d/<repo_name>.sources and map the current properties onto deb822 fields:

Property	Field
deb_src	Types: deb / deb deb-src
uri	URIs:
distribution	Suites:
components	Components:
arch	Architectures:
signed_by	Signed-By:
trusted	Trusted: yes

Two supporting changes:

• When writing the .sources file, delete a leftover <repo_name>.list so a repository switching formats does not end up defined twice. There is already a precedent for exactly this kind of cleanup in cleanup_legacy_file!:

  https://github.com/chef/chef/blob/61ad886b693750869d2b45d5ec6473dc26d3d251/lib/chef/resource/apt_repository.rb#L532-L547

• action :remove should delete both <repo_name>.list and <repo_name>.sources regardless of the property, which fixes the silent no-op described above.

I have deliberately proposed a property on the existing resource rather than a new resource, because it keeps the key-handling logic (install_key_from_uri, install_key_from_keyserver, keyring path, signed_by resolution) in one place. A separate resource is the other reasonable design — Ansible went that way with a dedicated deb822_repository module rather than extending apt_repository. I do not have a strong preference and would follow whichever direction maintainers prefer.

Describe the Need:

Anyone managing APT repositories with Chef on Debian or Ubuntu. The affected population grows with each release, since deb822 is already the OS default for the distribution's own sources and APT actively nudges users to convert third-party ones.

Two distinct groups:

• Users who simply want Chef-managed repositories to match the format the rest of the system uses. Not urgent — the one-line format works until at least 2029 — but currently impossible.
• Users who have run apt modernize-sources, who today get duplicate-source warnings on :add and a silently ineffective :remove. This group is affected regardless of whether they care about the format.

Current Alternative

Manage the .sources file directly with template or file. This means reimplementing key retrieval, dearmoring into /etc/apt/keyrings, and Signed-By wiring, which is the substantial part of what apt_repository provides. The file format itself is trivial; the key handling is not.

There is no cookbook-level alternative: the apt cookbook explicitly defers to chef-client for this resource ("The apt_repository resource has been moved into chef-client in Chef 12.9").

The remaining workaround is to tell operators not to run apt modernize-sources on Chef-managed hosts, which does not help when a release upgrade converts third-party sources for them.

Can We Help You Implement This?:

Yes. I am willing to submit a PR with RSpec coverage for the new property, the .list cleanup, and the :remove fix.

Before writing it I would like agreement on two points, since they change the shape of the patch significantly:

1. Property on apt_repository versus a separate resource.
2. Whether the :remove fix should be split into its own PR, given it is a bug fix that stands on its own and would be a candidate for backporting.

Happy to take direction on both.