settings: add network settings extension

[sam-berning]

Issue number:

Closes #3652

Description of changes:

Creates a network settings extension

Testing done:

Unit testing, built aws-dev variant and packaged settings-network in it. Tested on an ec2 instance.

network settings worked as expected, and the setting extension generation returned as expected:

bash-5.1# /usr/libexec/settings/network proto1 generate --setting-version v1
{
  "Complete": {
    "hostname": "ip-{instance public ip}.us-west-2.compute.internal"
  }
}

(EDIT 1-18)

Also built and tested a vmware-dev image, and the extension worked as expected:

bash-5.1# /usr/libexec/settings/network proto1 generate --setting-version v1
{
  "Complete": {
    "hostname": "{vm ip address}"
  }
}

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[cbgbt]

This looks right to me, other than the need to express a dependency on netdog in the RPM. Since this requires #3700, we should either open an issue or merge this after that PR has landed.

[cbgbt]

This should be expressed as an RPM dependency.

[cbgbt]

As mentioned elsewhere, we'll want to add the netdog RPM as a dependency here.

[cbgbt]

Likewise, we want to add a Requires: %{_cross_os}netdog

This symbol would only be available once we merge in #3700

[webern]

Likewise, we want to add a Requires: %{_cross_os}netdog

This symbol would only be available once we merge in #3700

Isn't it the other way around? Doesn't netdog depend on its settings extension?

Edit: oh I see, this extension calls out to netdog makes sense. This is a setting that relies on netdog to find its value.

[webern]

Likewise, we want to add a Requires: %{_cross_os}netdog

This symbol would only be available once we merge in #3700

Isn't it the other way around? Doesn't netdog depend on its settings extension?

Edit: oh I see, this extension calls out to netdog makes sense. This is a setting that relies on netdog to find its value.

[webern]

Suggested change

	settings-extension-ntp = { path = "../settings-extensions/ntp", version = "0.1" }
	settings-extension-container-registry = { path = "../settings-extensions/container-registry", version = "0.1" }
	settings-extension-updates = { path = "../settings-extensions/updates", version = "0.1" }
	settings-extension-network = { path = "../settings-extensions/network", version = "0.1" }
	settings-extension-container-registry = { path = "../settings-extensions/container-registry", version = "0.1" }
	settings-extension-network = { path = "../settings-extensions/network", version = "0.1" }
	settings-extension-ntp = { path = "../settings-extensions/ntp", version = "0.1" }
	settings-extension-updates = { path = "../settings-extensions/updates", version = "0.1" }

[webern]

Maybe keep these sorted?

[webern]

Can the braces be eliminated in these zero params Snafu struct constructions? (can't remember)

Suggested change

	Ok(ValidLinuxHostname::try_from(hostname).context(InvalidHostnameSnafu {})?)
	Ok(ValidLinuxHostname::try_from(hostname).context(InvalidHostnameSnafu)?)

[sam-berning]

looks like they can! updating

[webern]

Suggested change

	Ok(())
	// This settings field types handle validation during deserialization.
	Ok(())

[webern]

Add a test where the JSON fails to parse due to an invalid hostname or some other invalid field. It helps document the way the type enforces correctness of its input.