Add configurability in systemd to control default value of UseDomains parameter

[henryli001]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

What does the PR accomplish, why was it needed?

• Adds parameters to /etc/systemd/networkd.conf to allow controlling the default value of the UseDomain= parameter (for both dhcp v4 and v6).
• Backported from this change in the upstream

Change Log

• Add patch to allow configurability of "UseDomains=" for networkd

Does this affect the toolchain?

NO

Test Methodology

• Pipeline build id: https://dev.azure.com/mariner-org/mariner/_build/results?buildId=550114&view=results

[ddstreetmicrosoft]

technically looks ok, but these kind of user-facing parameters are dangerous to add into stable releases before upstreaming; we do not want to add and release a config param that our users start using, and then have upstream decide they want to do it differently, leaving us to clean up our own mess of having a parameter that (at best) is confusing to end users and adds maintenance burden or (at worst) directly conflicts with how upstream decides to implement it.

So with the caveat that this needs to be upstreamed first, it LGTM.

[henryli001]

technically looks ok, but these kind of user-facing parameters are dangerous to add into stable releases before upstreaming; we do not want to add and release a config param that our users start using, and then have upstream decide they want to do it differently, leaving us to clean up our own mess of having a parameter that (at best) is confusing to end users and adds maintenance burden or (at worst) directly conflicts with how upstream decides to implement it.

So with the caveat that this needs to be upstreamed first, it LGTM.

Makes sense to me. Will start working on the upstream change first and post the link here.

[henryli001]

technically looks ok, but these kind of user-facing parameters are dangerous to add into stable releases before upstreaming; we do not want to add and release a config param that our users start using, and then have upstream decide they want to do it differently, leaving us to clean up our own mess of having a parameter that (at best) is confusing to end users and adds maintenance burden or (at worst) directly conflicts with how upstream decides to implement it.
So with the caveat that this needs to be upstreamed first, it LGTM.

Makes sense to me. Will start working on the upstream change first and post the link here.

Upstream changes have been merged in: systemd/systemd#32194. Updated the patch here to align with the upstream changes.

[ddstreetmicrosoft]

LGTM but please patch azl3 also (preferably first)

[henryli001]

LGTM but please patch azl3 also (preferably first)

3.0 patching complete. Here's the PR link: #8799