generate: avoid calling 'udevadm control --reload' (LP: #1999178)

[slyon]

Description

The udev rules directories are monitored and re-loaded automatically with modern systemd-udevd. No need to manually reload them in the generator, causing side-effects.

We can still force-reload them when issuing netplan generate or netplan apply through the CLI, just to be on the safe side.

Replaces: #304

Checklist

• Runs make check successfully.
• Retains 100% code coverage (make check-coverage).
• New/changed keys in YAML format are documented.
• (Optional) Adds example YAML for new feature.
• (Optional) Closes an open bug in Launchpad. LP#1999178

[slyon]

Thinking about it. I feel like it should be fine just dropping the udevadm control --reload from the genrator binary. There shouldn't be any race conditions. Any .rules or .link files generated are written at systemd's generator stage. The systemd-udevd.service starts only afterwards and reads all available rules, before listening for kernel uevens (or triggering pending uevents). So we shouldn't miss any rule exection on first-boot/reboot.

At runtime, we can do whatever we need, through the Python CLI.

I'm pondering about adopting the autostart autopkgtest, which does a reboot test, adding some udev settings (like offloading flags) to the physical eth0 en* management interface of the test runner (ugh, we shouldn't fiddle with that, but it's the only physical interface we have).

[slyon]

We've used this in the Ubuntu devel series for a while now and didn't observe any fallout.
I feel relatively confident this works as expected and think it should be merged.

@daniloegea WDYT?

[daniloegea]

It seems to be working fine.

The only thing I've found so far, that might not be related to this change, is that the integration test TestNetworkManager.test_remove_virtual_interfaces from the "scenarios" is consistently failing on ppc64el in my backport of "1.0.1-1ubuntu2" to Noble, which includes this change. I'm still testing it to be sure this change is not causing problems.

[daniloegea]

The test I've been investigating seems to be flaky on ppc64el. After running it a bunch of times it passed once. But it's passing on Oracular where this patch is already present. It seems it's not related to it, I'll go ahead and merge this PR.