OOTB: Remove conditional compilation from `netdog`

[zmrow]

Removing conditional compilation from netdog may require a bit more detailed design. netdog currently needs to be aware of the network backend so it generates the proper configuration file format, and also needs to be aware of the platform (AWS/non-AWS) to understand how to generate the proper hostname.

Moving forward into an OOTB world, we do not want platform concepts to live at this layer of software. Ideally these mechanisms would be abstracted away and netdog would not need to understand the mechanisms, just discover and drive them.

A few options are lined out below:

Helper binaries (preferred option so far)

Similar design pattern to #3616 and settings extensions

• The parts of the program that are currently conditionally compiled will become their own discrete binaries and will be packaged as such.
• netdog will run discover and run those binaries to generate network config, generate hostname, etc.
• Create a metapackage bundling the proper set of helpers for each variant, the variant can then pull in the bundled set of helpers from this metapackage.

Pros

• Follows an already established pattern as settings extensions and early-boot-config.
• Flexible, allowing for variants to choose applicable bits.
• Extensible, different mechanisms can be packaged and implemented without changes to core netdog. For example, a different network backend could be supported through a new "config generation" binary.

Cons

• Additional binaries add complexity to packaging
• (Probably negligable) Additional binary size adds to total image size
• (Potentially negligable) Calling additional binaries could have time penalties at runtime

Other options that may be less desireable:

Configuration file to direct behavior

• Package a configuration file which netdog will read at runtime to determine its behavior.
• Remove all conditional compilation from netdog and compile all code, even if it is not applicable.

Pros

• Changes to netdog aren't extensive, mostly deletions of cfg directives

Cons

• Some netdog subcommands aren't applicable depending on the network backend.
• Raises the complexity of creating an OOTB as the user is required to create these files, be aware of their structure, etc.
• Does not allow for extensibility of netdog without interfering with the core program.

Multiple netdog packages

• Split netdog into multiple crates (netdog-lib, netdog-wicked, netdog-networkd).
• Create 2 packages netdog-wicked, netdog-networkd
• Variants will include the correct package for their needs

Pros

• Very deterministic behavior

Cons

• Not as extensible in the future, and future changes for OOTB may not fit neatly into a wicked or networkd package.