feat(ds-identify): add notfound=enabled-ds-none policy (#6895)

[grosbaloon]

Proposed Commit Message

feat(ds-identify): add notfound=enabled-ds-none policy (#6895)

When no datasource is detected, notfound=enabled leaves the result file
without a datasource_list, so cloud-init falls back to the list in
/etc/cloud/cloud.cfg and probes every datasource; notfound=disabled
turns cloud-init off entirely.

Add a third value enabled-ds-none that writes a datasource_list of just
None to /run/cloud-init/cloud.cfg and returns success, so cloud-init
boots on the None datasource.

Additional Context

Today an image built with a generic datasource_list in
/etc/cloud/cloud.cfg has two choices when ds-identify finds nothing:

policy	result when no datasource is identified
notfound=disabled	cloud-init does not run at all
notfound=enabled	cloud-init runs and probes every datasource in cloud.cfg, network ones included, which can add long timeouts to boot

Neither fits images that run both on clouds and on bare metal: on those
platforms we still want cloud-init to run (to apply the configuration
baked into the image via the None datasource) but without walking
the full datasource list and waiting on metadata services that do not exist.

notfound=enabled-ds-none covers that case: ds-identify writes

datasource_list: [ None ]

to /run/cloud-init/cloud.cfg and enables cloud-init. Behaviour when a
datasource is found is unchanged, and the existing enabled /
disabled values are untouched.

Notes for review:

• found None -- is called explicitly because found() only appends
  None to a non-empty list.
• In search mode, if writing the result file fails, cloud-init is
  disabled rather than enabled, since enabling it would fall back to the
  full search this policy is meant to avoid. In report mode the result
  is only informational (namespaced under di_report), so cloud-init is
  still reported as enabled.
• The new value is documented in the ds-identify header comment, which is
  where the other policy values are documented.

Test Steps

Unit tests:

tox -e py3 -- tests/unittests/test_ds_identify.py -k enabled_ds_none

On a live system where no datasource is identified (e.g. a local
QEMU/KVM VM with no NoCloud seed):

echo 'policy: search,found=all,maybe=none,notfound=enabled-ds-none' \
    | sudo tee /etc/cloud/ds-identify.cfg
# or on the kernel command line:
#   ci.di.policy=search,found=all,maybe=none,notfound=enabled-ds-none
sudo cloud-init clean --logs --reboot

After reboot:

root@ubuntu:~# cat /run/cloud-init/cloud.cfg
datasource_list: [ None ]
root@ubuntu:~# grep -i 'fallback datasource' /run/cloud-init/ds-identify.log
No ds found [mode=search, notfound=enabled-ds-none]. Writing fallback datasource list and enabling cloud-init [0].
root@ubuntu:~# cloud-init status --long 
status: done
extended_status: done
boot_status_code: enabled-by-generator
last_update: Thu, 01 Jan 1970 00:00:08 +0000
detail: DataSourceNone
errors: []
recoverable_errors: {}
root@ubuntu:~# systemd-analyze blame | grep cloud 
3.063s dev-disk-by\x2dpath-pci\x2d0000:00:01.1\x2data\x2d1.0\x2dpart-by\x2dlabel-cloudimg\x2drootfs.device
3.063s dev-disk-by\x2dlabel-cloudimg\x2drootfs.device
3.063s dev-disk-by\x2dpartlabel-cloudimg\x2drootfs.device
3.060s dev-disk-by\x2dpath-pci\x2d0000:00:01.1\x2data\x2d1.0\x2dpart-by\x2dpartlabel-cloudimg\x2drootfs.device
1.321s cloud-init-network.service
 747ms cloud-init-main.service
 363ms cloud-config.service
 163ms cloud-final.service
 108ms cloud-init-local.service
  32us cloud-init-hotplugd.socket

Report mode (dry run):

root@ubuntu:~# echo 'policy: report,found=all,maybe=none,notfound=enabled-ds-none' \
    | sudo tee /etc/cloud/ds-identify.cfg
root@ubuntu:~# sudo cloud-init clean --logs --reboot

root@ubuntu:~# cat /run/cloud-init/cloud.cfg 
di_report:
  datasource_list: [ None ]
root@ubuntu:~# 

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)