Running on OpenStack Ironic was broken in 1efa8a0a0,
which prevented a system configured to run on only
Openstack from actually running this ds. This change
also prevents the kernel commandline definition from
working. This change was required to prevent
unnecessarily probing OpenStack on Ec2, and is
therefore still required. 

This commit reverts an earlier attempt[1][2] to
automatically detect OpenStack, due to regression
it caused. Additionally, this change allows a
system that defines a datasource list containing
only [OpenStack] or [OpenStack, None] to attempt
running on OpenStack, overriding ds_detect(). A
datasource list that defines [OpenStack, None]
still falls back to DataSourceNone if OpenStack
fails to reach the IMDS.

This change also lays groundwork for the following
future work:

1. Add support for other datasources
2. Also override datasource checking when the kernel
   command line defines a datasource. This work needs
   to be done manually to support non-systemd systems.

Besides forcing OpenStack to run when it is the only
datasource in the datasource list, this commit also:

[1] 0220295 (it breaks some use cases)
[2] 29faf66 (no longer used)

LP: #2008727

Change "ca-certs" references to "ca_certs".

New certificates are written to individual files, with an incrementing
number as part of their filename, rather than all being placed in a
single file. This resolves issues caused when certificate files
containing more than a single certificate are placed in /etc/ssl/certs
(by utilities such as "update-ca-certificates" run by ca_certs).

Alpine / Debian / Ubuntu:

The current behaviour, whilst it works, is incorrect with regard to
the design of the underlying OS utilities for managing certificates.
For "remove_defaults" the system-installed certificate files should not
be actually deleted (otherwise it becomes problematic if someone wishes
to later re-enable one or more of them), rather they should be
deactivated and these OSes already provide the means to do so - this MR
modifies the certificate entries in the /etc/ca-certificates.conf file
by prefixing them with "!" - when the update-ca-certificate utility is
then run it will *not* place such delimited certificates into either the
/etc/ssl/certs/ directory (via symlinks) nor add them to the
(re)generated certificates bundle file.

Additionally it is incorrect for added certificates to be placed in the
/usr/share/ca-certificates directory - this location is intended for
standard/"official" certificates, the /usr/local/share/ca-certificates
directory is intended for "local" or "site-specific" certificates and so
this PR adds them there instead - for certs in
/usr/local/share/ca-certificates the update-ca-certificates utility will
automatically use them, there is *no* need to add their filenames to the
/etc/ca-certificates.conf file.

LP: #1931174

LP: #1815990

Fixes the creation of single partitions on MBR devices. Currently this
fails with the following debug output:

cc_disk_setup.py[DEBUG]: Calculating partition layout
cc_disk_setup.py[DEBUG]:    Layout is: 0,
cc_disk_setup.py[DEBUG]: Creating partition table on /dev/sdb
subp.py[DEBUG]: Running command ['/sbin/sfdisk', '--Linux', '--unit=S',
'--force', '/dev/sdb'] with allowed return codes [0] (shell=False,
capture=True)
util.py[DEBUG]: Creating partition on /dev/sdb took 0.237 seconds
util.py[WARNING]: Failed partitioning operation
Failed to partition device /dev/sdb
Unexpected error while running command.
Command: ['/sbin/sfdisk/', '--Linux', '--unit=S', '--force', '/dev/sdb']
Exit code: 1
Reason: -
Stdout: Checking that no-one is using this disk right now ... OK

        Disk /dev/sdb: 16 MiB, 16777216 bytes, 32768 sectors
        Disk model: HARDDISK
        Units: sectors of 1 * 512 = 512 bytes
        Sector size (logical/physical): 512 bytes / 512 bytes
        I/O size (minimum/optimal): 512 bytes / 512 bytes

        >>> Created a new DOS disklabel with disk identifier 0xb3604c9a.
        /dev/sdb1: Leaving.
Stderr: sfdisk: --Linux option is unnecessary and deprecated
        Start sector 0 out of range.
        Failed to add #1 partition: Result not representable
util.py[DEBUG]: Failed partitioning operation

On a BIOS/MBR partitioned device the 1st partition cannot start at sector
0 as this is reserved for the MBR.

Documentation clarifications/corrections and additional examples added.

Also remove "--Linux" and "--unit=S" options from sfdisk calls, these
options have been deprecated since October 2014.

Note: This is not a change of behavior because the change provoking
the error was introduced in util-linux 2.26 in Xenial. Thus, every
supported cloud-init version fails.

LP: #1851438

test/doc: Fix typo with package_update/package_upgrade

There's a typo in the docs that can lead to confusion.
packages_update > package_update
packages_upgrade > package_upgrade

NoCloud meta-data seedfrom (or kernel commandline seedfrom) URL can
now provide variable expansion for system-specific DMI values as seen
in /sys/class/dmi/id on Linux or kenv on FreeBSD platforms.

Variable names of the format __dmi.SOME_VAR__ will be replaced when
determining the URL from which NoCloud datasource GETs its user-data
and meta-data.

This allows for a common templated seedfrom URL which can be reused
for mass deployments, but can allow for unique URLs based on classes
of DMI system characteristics such as chassis serial, product name,
UUID etc.

LP: #1994980

The cloud-config schema definition standardizes on underscores
instead of hyphenated key names. This makes for standard config keys
and reduces the burden of supporting aliases for either hyphenated or
underscore-delimited keys.

Configure and run ansible controller instance during boot

New Features:
-------------
- pull one or more playbooks from (optionally private) repositories using deploy keys
- playbook execution: execute one or more playbooks during boot
- support for ansible pip install as custom user
- new example docs showing how to bootstrap nodes for control by ansible
- example demonstrating ansible controller server setup
- example using ansible to launch and configure instances using a supported datasource (LXD)

Config Files and SSH Keys:
--------------------------
Some existing modules already provide desirable behavior for
writing out inventory configuration, ansible.cfg, and other
configuration files. See examples for more details.

Line 3 was stating that the "ubuntu" group is created while the yml indicates "sysadmin"

Also add schema entries for the base config modules lists that can be
overridden with user data.