netdog: Add initial networkd config structs and associated Display macro

[zmrow]

Issue number:
Related to #2449

Description of changes:
This is the first in a series of changes to netdog that add the ability to generate systemd-networkd config files. This PR adds the initial set of structs that represent the two kinds of systemd-networkd config files we currently use: .network and .netdev. These structs contain the config entries we currently will make use of; it is expected they will grow over time.

These structs must be serialized to file. Though a serde library exists for INI, systemd doesn't strictly follow INI spec as it allows for duplicate sections and duplicate keys within a section. Rather than hack around the library, I opted to write a proc macro that generates Display implementations in the systemd unit format for the structs so the user can serialize the structs to string/file. The proc macro allows for annotation of structs that represent config file sections, as well as fields that represent entries within the sections.

This allows us to write the following:

// Very abbreviated example
#[derive(SystemdUnit)]
struct NetworkConfig {
    match_section: Option<MatchSection>
}

#[derive(SystemdUnitSection)
#[systemd(section = "Match")] // The name of the networkd config section
struct MatchSection {
    #[systemd(entry = "Name")] // The name of the networkd config entry
    name: Option<String>
}

which would represent the following section of a .network file:

[Match]
Name=...

Testing done:

• All unit tests continue to pass
  Additional integration tests to come as the code is added to build these structs.

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.

[yeazelm]

I didn't deeply review the proc_macro or darling usage but the Networkd specifics all look right!

[zmrow]

^ Addresses all the comments...

(Ugh, I rebased onto develop and didn't push before I added my updates... 😢 Sorry about that)

[arnaldo2792]

I may benefit from this crate. Would it make sense to make it its own lib in sources out of api? We could name the crate systemd-lib and extend it as needed. I already know I want to have a function to receive the file descriptors passed by systemd, and I was planning to have this as a standalone lib that may be used by other “dogs”. We will use this both in EFS utils replacement, and when we decide to implement socket activation for API server.

[zmrow]

I don't mind if the macros move out of netdog, but I'd rather not conflate these macros as part of a larger systemd-related "library" crate.

[bcressey]

LGTM. Just a few documentation nits.

[bcressey]

Is there an attribute that ensures this property?

[zmrow]

Yes, but indirectly :)

The attribute supports(struct_named) on the containing struct SystemdUnitSection ensures the macro only supports structs with named fields. This means it does not support tuple or newtype structs.

SystemdUnitSectionField derives FromField, meaning it can only be "deserialized" from a struct field, and given the above struct_named attribute is guaranteed to have an ident/name.

[zmrow]

Regardless - if the developer attempted to do "the wrong thing" here, it would be a compile-time issue printing out the expect message.

[zmrow]

Fixed up @bcressey 's requests